我想知道 DAO 应该处理多少业务逻辑。
好的，我们都知道 DAO 的目的是封装数据访问并隐藏有关它的所有信息以及实现。此外，DAO 的目标也是将业务逻辑与数据访问逻辑分离。
我会争辩说，DAO 中必须有一些业务逻辑，例如，如果由于特定领域的某些要求而无法删除或更新业务对象怎么办？我想没有人会为那个 DAO 实现删除/更新方法，而且——在我看来——这意味着一些业务逻辑的知识。
现在，您可以想象我的问题更多的是概念性而非实际性，因此使用 ORM 是无用的建议，因为没有具体的使用场景。
问题是：如果对持久数据的操作有任何限制，DAO 应该处理多少业务逻辑？
示例：
BusinessObject1在其生命周期内只能更新一次。假设我们可以很容易地知道它是否已经更新，如果我们BusinessObject1再次尝试更新，DAO 是否应该抛出异常？或者它应该什么都没有检测到，这应该在业务层中进行管理？
如果您将数据存储在具有参照完整性规则的数据库中，那么您的数据层中就有业务规则。
这是所有经验法则的问题。他们工作，直到他们没有。重点不是要避免数据层中的规则，重点是只将规则放在属于那里的数据层中。例如，强制存储数据有效性的规则属于数据层。强制数据使用方式的规则不属于数据层。
你担心的是
如果由于特定领域的某些要求而无法删除或更新业务对象怎么办？
我认为将业务逻辑与 DAO 分开仍然是一个好主意，因为它的业务大部分时间都在不断变化。因此，如果您的要求是在执行 update n delete 时设置业务约束，那么服务层应该检查这个约束。这样您就不必在 DAO 层中进行任何更改。
此外，如果将来您想切换到另一个数据库，那么您也不必担心业务逻辑，因为您只需要关注数据库特定的操作。
您可以在您的 DAO 中定义限制BusinessObject1（例如：只能更新 1 次），您的 DAO 将读取这些限制。然后当你给 DAO 一个修改过的对象并告诉他持久化这个修改（更新）时，DAO 会抛出一个异常。
我认为这就是 Doctrine（数据映射器 ORM）的工作原理。
如果您的应用程序被划分为彼此独立的组件，那么您最终会得到一个业务组件、一个数据库组件（可能实现为 DAO）和一个 UI 组件。业务逻辑组件负责执行应用程序背后的核心业务规则；数据库组件，用于访问数据和执行数据操作规则；最后是 UI 组件，用于控制与用户的交互。
有了这样的设计，就没有关于数据库组件是否应该包含逻辑的争论：当然应该。它需要规则来管理数据的存储、检索和解释方式。但是，它包含的逻辑类型不同于业务逻辑或 UI 逻辑。而且，正如已经指出的，数据库组件不必是软件组件；它可能由数据库中的存储过程、函数和触发器组成。
底线是，随意将逻辑放入您的 DAO 中，但确保此类逻辑仅适用于与数据访问相关的操作。同样，在您的 UI 组件中包含逻辑来驱动与用户的交互也很好。