【问题标题】：Is it OK to bypass business-tier in a mostly CRUD application?在主要是 CRUD 应用程序中绕过业务层是否可以？
【发布时间】：2014-04-09 23:27:21
【问题描述】：

我正在开发一个应用程序，其中绝大多数功能是数据库表和视图之间的一对一映射。到目前为止，它是一个纯粹的 CRUD 应用程序。

但是，在少数情况下会涉及到一些业务规则。例如，如果用户正在创建“受限测试”，则需要输入公司信息，但如果不是“受限测试”，则公司信息是可选的。

在这些场景中是否可以让视图直接使用数据库对象而无需中间业务对象，并且只在涉及业务规则的情况下实现业务对象？

作为一个附带问题，我使用的 ORM 框架不允许我在实体字段上实现 getter/setter 代码。因此，这些实体对象上的所有字段本质上都是公共的，可以随意更改。这是否足以为每个实体类创建一个“业务对象”来保护 PK 等不变量？

编辑：

我确实找到了 Mark Seemann 的一篇非常有用的帖子，它似乎很好地回答了我大约一半的问题。 http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/

【问题讨论】：

标签： orm architecture crud business-logic-layer

【解决方案1】：

是的，可以绕过 crud 中的服务。可以产生一个crud但是......你确定它在6个月内仍然是一个crud吗？你能预测新的业务需求吗？因为如果新的逻辑来了，它会慢慢来，一个接一个的要求。您会注意到必须重写分层的那一刻吗？您能否让企业相信您需要时间和金钱来支付这种改变？和其他开发人员花时间重写代码？

所以从设计的角度来看：是的，完全没问题。但在现实生活中可能很危险

【讨论】：

如果我需要在时机成熟时进行重构，我认为没有问题，但是，您提供了我以前从未想过的见解。我特别喜欢关于业务需求逐渐渗透的观点，并且能够说服业务部门花费更多时间和金钱进行重构。感谢您的评论。

【解决方案2】：

理想情况下，您应该使用业务层，尤其是在使用 ORM 时。当您使用 ORM 时，实体会相互引用。

您永远不知道何时需要拆分、合并传入的业务对象以适应数据层。

您永远不知道以后是否要添加一些业务逻辑。因此，即使您目前没有进行任何转换，也最好有一个单独的层。

【讨论】：