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