我的一些域类变得相当丰富：它们实现了一个有趣的可比较，可能有加号，减号，乘法和div，许多都有一些方便的getter来调用服务并确定复杂的东西。最重要的是，他们拥有合适的属性。我正在将这两者用于正常的“数据库事务”，并且在我只想要一个具有所有这些方法但可能不想保存它的对象的时候。
我的队友确信这非常糟糕，并建议我应该使用DTO（数据传输对象），根据我的理解，这将是一个POGO / POJO，其中一个域类'代码复制/粘贴在这看起来真的不干，我看不出有什么好处。将域对象不时用作常规对象有什么问题吗？我错过了DTO的观点吗？
答案 0 :(得分：5)
Grails域类有些错误，因为应用程序的域层通常由持久类和非持久类组成。但是Grails域类总是持久的。您可以拥有非持久域（在传统意义上）类，但它们必须位于src / groovy或src / java中。这可能令人沮丧，因为域应用程序在应用程序中分为两个部分。我们已经有了非持久域类的请求，例如像static persistent = false或类似的东西，但它还没有实现。
我认为如果你想利用域类的非持久性功能（例如验证，依赖注入等），那么可以使用一些可以由数据库支持但不支持的类。您只需要在代码中记录它或具有某种约定，例如特殊的包结构或命名约定。如果您从不调用save()，list()，findAllByFoo()等GORM方法，那么就不会有任何数据库访问权限。
就DTO而言，它们可以是非干的，但有一个插件可以提供帮助 - 请参阅http://grails.org/plugin/dto。它有一段时间没有更新，但我很确定它仍然有效。它有一个很好的功能，它将使用语法domainObj as DTO从持久域类实例创建DTO实例。您确实需要在类之间保持同步更改，但是通过脚本自动生成初始DTO。
答案 1 :(得分：1)
我认为你走的是正确的道路。
1 - 只需要创建一个类来处理域类，就可以使模型更加耦合。您正在创建更多依赖项，这显然很糟糕。你的物品应该能够照顾好自己。
2 - 你的朋友正在谈论的模型实际上被称为Anemic Domain Model，你的数据与你的程序的逻辑分开，它首先由Martin Fowler描述为反模式。逻辑和数据之间的这种分离在程序编程中非常常用，但在面向对象编程中却没有（OOP的目的恰恰相反）。
3 - 减少代码重用。
4 - 一旦必须初始化与数据分离的逻辑，就更难测试。与此同时，数据会通过您的系统泄漏。
DTO是你可以使用的东西，当然。但不建议您这样做。它最初设计用于通过进程或层来传输数据（对象）。然后，由于某种原因，人们开始在层之间使用它，这是不值得的。使您的程序更复杂（一旦您将这些实体分布在您的应用程序中），它就允许全局访问。
您正在做的事情称为Rich Domain Model，使用它没有问题。但是，当然你应该小心。如果你看到你的班级承担了太多的责任，那么也许是时候设计另一个课程来帮助（也许你违反了SRP原则）。
看看如何在Grails中设计域对象。他们鼓励您编写丰富的模型（验证，数据库事务等）。