在 grails 域类中编写类方法的优缺点是什么？答案

【问题标题】：What are the pros and cons of writing class methods in grails domain classes?在 grails 域类中编写类方法的优缺点是什么？
【发布时间】：2012-12-24 03:28:33
【问题描述】：

在 grails 领域类中编写类方法的优缺点是什么？我在问，因为我经常在域类中看不到任何带有方法的 grails 项目，只有数据成员。这样做有什么坏处吗？

【问题讨论】：

标签： grails groovy grails-domain-class

【解决方案1】：

当一个领域类（不仅在 grails 中，而且在一般的面向对象编程中）时，这被称为anemic domain model。 Martin Fowler 建议将域逻辑放入域类中以创建丰富的域模型。通过这样做，域类变得更智能并且知道如何执行操作，而不是让另一个服务类必须对域类进行操作。拥有丰富的领域模型的优点是类封装了更多自己的行为，并且更加自包含。另一方面，它确实使域类更加复杂。虽然我认为领域类应该不仅仅是一个业务对象。

在 grails 中，我倾向于尝试结合使用丰富的域模型和使用服务。很难对方法何时应该在域类中以及何时应该在服务中做出笼统的陈述。不过，作为一般规则，如果一个操作很复杂并且需要多个协作者，我倾向于将它放在一个服务类中。如果方法看起来应该是领域类的行为，我会把它放在那里。

举一个更具体的例子，让我们以 Person 类为例。

class Person {
  String firstName
  String lastName
  List<Person> friends
}

在我们的应用程序中，一个人可以说话。现在我可以拥有一个知道一个人如何说话的TalkService。但在这种情况下，我认为talk是人的核心行为，所以我会在Person中添加一个talk方法。

假设我还有一个功能，我想找到人的朋友的所有朋友（二级朋友）。对我来说，这不是 Person 的核心行为，所以我会将其委托给服务。

总结一下，一般来说，当域类是对象的核心行为（例如，它是域方法）时，我会将其添加到域类中，否则，我会将其放入服务中。

【讨论】：

【解决方案2】：

在 Java 项目中，您必须具有表示模型的 POJO 类。例如：人员、发票、书籍……

然后是服务层，它包含用户做一些数据库查询的接口，它接受你的模型参数，并返回模型，还有负责重定向和注入你的服务的控制器层。

在 grails 中，将服务注入控制器非常容易

现在，我们什么时候需要在域类中使用方法？只有模型负责我们需要做什么，例如，Person X 的年龄（从出生日期算起），Invoice 中存在多少项目（从 List 算起），认为是我们只有在我们操作当前对象的数据时才使用它。

例如，对于保存方法，您不能将其添加到模型中

人员控制器：

def personService

def save() {
...
Person person = ...
personService.save(person);
...
}

这更具进化性

【讨论】：