tmh*_*tmh 6 oop database-design dao design-patterns
我想知道DAO应该处理的业务逻辑数量.
好的,我们都知道DAO的目的是封装数据访问并隐藏有关它的所有信息以及实现.此外,DAO的目标还在于将业务逻辑与数据访问逻辑分开.
我认为DAO 必须有一些业务逻辑,例如,如果由于特定域的某些要求而无法删除或更新业务对象,该怎么办？我想没有人会为那个DAO实现删除/更新方法,而且 - 正如我所看到的 - 这意味着对业务逻辑的一些了解.
现在,你可以想象我的问题更具概念性而非实际性,因此使用ORM是没有用的建议,因为没有具体的使用场景.
问题是:鉴于对持久数据的操纵有任何限制,DAO应该处理多少业务逻辑？
示例:
BusinessObject1在其生命周期中只能更新一次.假设我们可以很容易地知道它是否已经更新,如果我们尝试BusinessObject1再次更新DAO会抛出异常吗？或者它应该检测不到任何东西,这应该在业务层管理？
如果将数据存储在具有参照完整性规则的数据库中,则数据层中包含业务规则.
这是所有经验法则的问题.他们工作直到他们不工作.关键是不要避免数据层中的规则,关键是只将规则放在属于那里的数据层中.例如,强制存储数据有效性的规则属于数据层.强制执行数据使用方式的规则不属于数据层.
您可以在您的 DAO 中定义限制BusinessObject1（例如：只能更新 1 次），您的 DAO 将读取这些限制。然后，当您向 DAO 提供修改后的对象并告诉他保留该修改（更新）时，DAO 将抛出异常。
我认为这就是 Doctrine（数据映射器 ORM）的工作原理。