logo标签列表

DAO和业务逻辑

oopdesign-patternsdatabase-designdao
6
我想了解DAO应该处理多少业务逻辑。
我们都知道DAO的目的是封装数据访问并隐藏所有相关信息以及实现细节。此外，DAO的目标还在于将业务逻辑与数据访问逻辑分离。
我认为DAO必须包含一些业务逻辑，例如，如果由于特定领域的要求而无法删除或更新某个业务对象怎么办？ 我想没有人会为该DAO实现删除/更新方法，因为这意味着对业务逻辑有一定的了解。
现在，你可以想象我的问题更多地是概念性的，所以建议使用ORM是无用的，因为没有具体的使用场景。
问题是：考虑到对持久数据操作的任何限制，DAO应该处理多少业务逻辑？
例如：BusinessObject1只能在其生命周期内更新一次。 假设我们可以轻松知道它是否已经被更新过，那么当我们尝试再次更新BusinessObject1时，DAO应该抛出异常吗？ 还是应该检测不到，并在业务层面进行管理？
被标记为不当，不是因为这是一个坏问题，而是这可能不是最适合的论坛（似乎更适合http://programmers.stackexchange.com/）。基于该问题无法得到合理回答，“可能引起辩论、争论、投票或长时间讨论”，因此被标记为不当。我曾考虑过将其标记为“不是问题”，因为它“模糊、不完整、过于宽泛或具有修辞性，在当前形式下无法得到合理回答”。无论如何，我认为它无法编辑成更合适的形式，因为这是一个主观问题。 - chrisbunney
4个回答
11
如果您将数据存储在具有引用完整性规则的数据库中，则您的数据层具有业务规则。
所有经验法则的问题在于它们有效，直到不再有效。重点不是要避免在数据层中使用规则，而是只在数据层中放置适合的规则。例如，强制执行存储数据的有效性的规则属于数据层。强制执行如何使用数据的规则则不属于数据层。
因此，在上面的示例中，DAO 不应关心谁、何时以及如何“访问”数据，但应关心谁/何时/如何“修改”它们？ - kelo
1
@tmh - 这并不是关于读取 vs. 写入的问题。而是关于事务提交时数据看起来像什么。因此，修改数据的人/时间可能根本不是数据层面的问题。这并不意味着 RDBMS 没有很多这方面的功能 - 它们确实有。然而，安全规则是应用程序关注的问题，而不是存储关注的问题。这种区别是合乎逻辑的。您的物理实现可能出于实际原因利用 RBDMS 的安全功能。 - Joel Brown
这是很久以前的事情了，我偶然发现了这个旧答案和旧评论，而且时代已经变化，所以我想补充一下关于RDBMS安全特性的想法。安全应该是分层的，因此您应该在数据层中包含安全规则，因为“更多的安全性更好”的经验法则比“不要将业务逻辑放在数据层中”更重要。 - Joel Brown
0
你可以在你的BusinessObject1中定义限制条件（例如：只能更新一次），然后你的DAO将读取这些条件。当你向DAO提供一个修改过的对象并告诉它要持久化该修改（更新）时，DAO将抛出异常。
我认为这就是Doctrine（一种数据映射ORM）的工作方式。
0

您的关注点是

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

我认为将业务逻辑与 DAO 分开仍然是一个好主意，因为业务在大多数情况下都会发生变化。因此，如果您的要求是在更新和删除时放置业务约束，则服务层应该检查这些约束。这样做，您就不必对 DAO 层进行任何更改。

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

0

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

在这样的设计中，关于数据库组件是否应该包含逻辑的争论是没有意义的：当然应该包含逻辑。它需要规定数据的存储、检索和解释方式的规则。然而，它所包含的逻辑与业务逻辑或UI逻辑不同。并且，正如前面所指出的，数据库组件不一定需要是一个软件组件；它可以由数据库中的存储过程、函数和触发器组成。

总之，您可以自由地在DAO中放置逻辑，但请确保此类逻辑仅涉及与数据访问相关的操作。同样，将逻辑放置在UI组件中以驱动与用户的交互也是可以的。

谢谢你的回答。你认为上面例子中的逻辑属于数据层吗？ - kelo
如果您的数据库组件仅被一个应用程序使用，并且需要在持久化级别上遵循此规则，那么只要以列和行的形式表达而不是业务对象的形式，在数据层实现该逻辑就可以了。 - user1342582
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接