DAO 和业务逻辑 [关闭]答案

【问题标题】：DAO & Business Logic [closed]DAO 和业务逻辑 [关闭]
【发布时间】：2012-08-26 03:56:41
【问题描述】：

我想知道 DAO 应该处理多少业务逻辑。

好的，我们都知道 DAO 的目的是封装数据访问并隐藏有关它的所有信息以及实现。此外，DAO 的目标也是将业务逻辑与数据访问逻辑分离。

我认为 DAO 必须包含一些业务逻辑，例如如果由于特定领域的某些要求而无法删除或更新业务对象怎么办？我猜没有人会为那个 DAO 实现删除/更新方法，而且——在我看来——这意味着一些业务逻辑知识。

现在，您可以想象我的问题更多的是概念性而非实际性，因此使用 ORM 是无用的建议，因为没有具体的使用场景。

问题是：如果对持久数据的操作有任何限制，DAO 应该处理多少业务逻辑？

示例：
BusinessObject1 在其生命周期内只能更新一次。假设我们可以很容易地知道它是否已经更新，如果我们再次尝试更新BusinessObject1，DAO 是否应该抛出异常？或者它应该什么都没有检测到，这应该在业务层进行管理？

【问题讨论】：

已标记，并不是因为它本身是一个坏问题，但这可能不是最好的论坛（似乎更适合programmers.stackexchange.com）。以无法合理回答问题为由标记为不适当，“可能会引发辩论、争论、投票或扩展讨论”。我确实认为标记为“不是问题”，因为它“模棱两可、模糊、不完整、过于宽泛或修辞，无法以目前的形式得到合理的回答”。无论如何，我认为它不能被编辑成更合适的形式，因为这是一个主观问题

【解决方案1】：

如果您将数据存储在具有参照完整性规则的数据库中，那么您的数据层中就有业务规则。

这是所有经验法则的问题。他们工作，直到他们没有。重点不是要避免数据层中的规则，重点是只将规则放在属于那里的数据层中。例如，强制存储数据的有效性的规则属于数据层。强制数据使用方式的规则不属于数据层。

【讨论】：

因此在上面的示例中，DAO 不应该关心谁、何时以及如何访问数据，而是应该关心谁/何时/如何修改他们？
@tmh - 这与 read 与 write 的区别不大。它是关于提交事务时数据的样子。因此，谁/何时修改数据可能根本不是数据层问题。这并不是说 RDBMS 没有很多功能 - 他们有。但是，有关安全性的规则是应用程序问题而不是存储问题。这种区分是合乎逻辑的。出于实际原因，您的物理实现可能会利用 RBDMS 的安全功能。
这是很久以前的事了，我遇到了这个旧答案和旧评论，而且情况已经发生了变化，所以我将进一步思考：RDBMS 的安全特性。安全性应该是多层次的，因此您应该在数据层中包含安全规则，因为“安全性越高越好”的经验法则胜过“不要将业务逻辑放在数据层中”的经验法则。

【解决方案2】：

您可以在您的 BusinessObject1 中定义限制（例如：只能更新 1 次），您的 DAO 将读取这些限制。然后当你给 DAO 一个修改过的对象并告诉他持久化这个修改（更新）时，DAO 会抛出一个异常。

我认为这就是 Doctrine（数据映射器 ORM）的工作原理。

【讨论】：

【解决方案3】：

你担心的是

如果业务对象由于某些原因无法删除或更新怎么办？特定领域的要求？

我认为将业务逻辑与 DAO 分开仍然是一个好主意，因为它的业务大部分时间都在不断变化。因此，如果您的要求是在执行 update n delete 时设置业务约束，那么服务层应该检查这个约束。这样您就不必对 DAO 层进行任何更改。

此外，如果将来您想切换到另一个数据库，那么您也不必担心业务逻辑，因为您只需要专注于特定于数据库的操作。

【讨论】：

【解决方案4】：

如果您的应用程序被划分为相互独立的组件，您最终会得到一个业务组件、一个数据库组件（可能实现为 DAO）和一个 UI 组件。业务逻辑组件负责执行应用程序背后的核心业务规则；数据库组件，用于访问数据和执行数据操作规则；最后是 UI 组件，用于控制与用户的交互。

有了这样的设计，数据库组件是否应该包含逻辑是没有争议的：当然应该。 它需要规则来管理数据的存储、检索和解释方式。但是，它包含的逻辑类型不同于业务逻辑或 UI 逻辑。而且，正如已经指出的，数据库组件不必是软件组件；它可能由数据库中的存储过程、函数和触发器组成。

底线是，您可以随意在您的 DAO 中添加逻辑，但要确保此类逻辑仅适用于与数据访问相关的操作。同样，在 UI 组件中包含逻辑来驱动与用户的交互也很好。

【讨论】：