我的问题可能有点基础，但想通过Stack Overflow人员来运行。
通常的做法是拥有Domain类（带有属性和getter / setter，比如User.java）。然后让DAO（表示扩展GenericDAO.java的UserDAO.java）提供CRUD操作。
如果我们让域扩展GenericDAO怎么办？就像User.java扩展GenericDAO一样，它允许我们有这样的东西：
user.save();
我曾在Grails工作，如果你了解Grails，你就会理解为什么会这个问题。还有一点关于域驱动设计的想法，我想这类似的建议。我发现an article on DDD说：
客户端应始终调用域对象，而域对象又应调用DAO来将数据持久保存到数据存储中。
只是想知道人们为什么不以这种方式使用它？
答案 0 :(得分：1)
如果我们让域扩展GenericDAO怎么办？像User.java一样扩展 GenericDAO，它允许我们有这样的东西：
您如何知道此域模型的使用者需要该方法（save()）？例如，User可以在使用User将DAO持久保存到数据库中的Web服务中使用。同样的User也会发送到响应对象中的Web服务客户端。为什么将持久层打包在Web服务客户端上是有意义的？它只会使Web客户端消费者感到困惑，因为save()在那里没有意义。
只是想知道人们为什么不使用它们有任何缺点 这样吗？
从我的角度来看，这是一种关注点的分离。 User是一个模型。它的责任是代表User的状态。 UserDAO是持久层的一部分。它的职责是将模型持久化到持久性存储（例如数据库）。通过混合这两者，你可以紧密地结合这些功能。
答案 1 :(得分：0)
主要关于Single Responsibility Principle和关注点的分离 - 在DDD中，域层对象专门用于建模域并强制执行其不变量。是否，如何或何时持久保存数据不属于他们的业务，这些是其他代码模块处理的不同问题。
SRP和较小类范围的一些好处是：可读性和理性能力（您确切地知道在打开/调试类时会发生什么），更小的测试，更少的脆弱性（对类的更改影响有限），独立可部署。
在DDD和更集成的方法（如一个（G）Rails推广）之间进行选择基本上是在时间的柔和性（改变程序的一个方面的能力，对代码库的影响最小）和即时生产力之间的权衡。无论是对还是错，这只是一个背景问题。