在大多数CRUD应用程序中绕过业务层是否可以？

Question

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

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

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

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

编辑：

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

Answer 1

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

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

Answer 2

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

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

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