Orm 在一个以CRUD为主的应用程序中绕过业务层可以吗？

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

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

在这些场景中，让视图直接使用数据库对象而不使用中间业务对象，并且仅在涉及业务规则的情况下实现业务对象，这样可以吗

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

编辑：

---

我确实找到了马克·希曼的一篇非常有用的帖子，它似乎很好地回答了我一半的问题

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

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

---

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

是的，可以绕过crud中的服务。可以生成积垢，但是。。。你确定6个月后它仍然是积垢吗？您能否预测新的业务需求。因为如果新的逻辑出现，它将缓慢出现，一个接一个的需求。你会注意到你必须重写分层的时刻吗？你能说服公司你需要时间和金钱来支付改变吗？和其他开发人员花时间重写代码

---

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

如果到时候需要重构，我看不出有什么问题，但是，您提供了我以前从未想到过的见解。我特别喜欢业务需求逐渐进入，并且能够说服业务部门花更多的时间和金钱进行重构。谢谢你的评论。