为什么不直接扩展GenericDAO？

Question

我的问题可能有点基础，但希望通过堆栈溢出的人运行这一点。

通常的做法是拥有域类(属性和getter/setter，比如User.java)。然后让DAOs (扩展了UserDAO.java的GenericDAO.java)提供CRUD操作。

如果我们让域扩展GenericDAO呢？像User.java一样，扩展了GenericDAO，它允许我们拥有这样的东西：

user.save();

我研究过Grails，如果你知道Grails，你就会明白为什么要问这个问题。还有一些关于领域驱动设计的想法，我想这也是类似的建议。我找到一篇关于DDD的文章，上面写着：

客户端应该始终调用域对象，而域对象又应该调用DAO来将数据持久化到数据存储区。

我只想知道为什么人们不这么做有什么坏处吗？

Answer 1

如果我们让域扩展GenericDAO呢？像User.java一样，扩展了GenericDAO，它允许我们拥有这样的东西：

您如何知道此域模型的使用者将需要该方法(save())？例如，可以在使用User将User保存到数据库的web服务中使用DAO。同样的User也被发送到响应对象中的web服务客户端。为什么要将持久化层打包到web服务客户端上呢？它只会让web客户端用户感到困惑，因为save()在那里没有意义。

我只想知道为什么人们不这么做有什么坏处吗？

在我看来，这是一种关注点的分离。User是一个模型。它的责任是代表User的状态。UserDAO是持久化层的一部分。它的责任是将模型持久化到持久性存储中(例如数据库)。通过将这两种功能混合在一起，可以将功能紧密地结合在一起。

Answer 2

它主要是关于单一责任原则和关注点的分离--在DDD中，域层对象专门用于域的建模和不变量的执行。不管数据是如何持久化的，何时持久化都不是他们的事，这些都是其他代码模块处理的不同的关注点。

SRP和较小的类范围的一些优点是:可读性和合理性(您知道在打开/调试类时所期望的是什么)、更小的测试、更少的脆弱性(对类的更改影响有限)、独立的部署性。

在DDD和更集成的方法(如one (G)Rails )之间进行选择，基本上是在时间上的柔性(改变对代码库的影响最小的程序的某一方面)和即时生产力之间的权衡。无论是对是错，这只是一个背景问题。