应该在域类中使用什么逻辑以及Grails中的服务应该包含哪些内容？

Question

我正在开发我的第一个Grails应用程序，它涉及移植旧的struts web应用程序。有很多现有的功能，当我移动时，我很难确定服务中应该包含什么以及应该直接包含在模型中的内容？

从大多数Ruby on Rails开发的背景出发，我强烈倾向于将几乎所有内容都放在与它相关的域类中。但是，如果应用程序与我移植的应用程序一样大，那么有些类最终会成千上万行。

您如何决定应该在域中进行什么以及应该在服务中进行哪些操作？有没有既定的最佳实践？我做了一些环顾四周，但大多数人似乎只是承认这个问题。

Answer 1

一般来说，我遵循的主要准则是：

  

如果一大块逻辑与多个域类相关，请将其放入服务中，否则它将进入域类。

如果没有关于你正在处理什么样的逻辑的更多细节，那么很难比这更深入，但这里有一些更普遍的想法：

1. 对于与视图呈现相关的内容，它们会进入标记库（或可能是服务）
2. 有关确定要发送到视图的内容以及将其发送到哪个视图的内容，可以在控制器（或可能是服务）中进行。
3. 对于与外部实体（即文件系统，队列等）对话的内容，那些进入服务的内容

总的来说，我倾向于错误地提供太多服务，而不是把事情搞得太紧张。最后，所有关于你最有意义的是什么，以及你如何看待代码以及如何维护代码。

然而，我要注意的一件事是，您移植的内容可能存在高级别的代码重复。由于Grails是在Groovy上构建的，并且可以访问更强大的编程方法（如Closures），因此您可以清理并简化 代码。

Answer 2

我个人认为这不仅是服务和域类之间的决定，还包括插件或注入代码。

想想像Book.findAllByName()这样的动态查找器。 Grails将它们注入到域类中是很棒的。否则，它们必须被复制到每个域类，或者它们可以通过服务（dynamicFinderService.findAllByName('Book') -argh）进行调用。

所以在我的项目中，我有很多东西可以移动到插件并注入域类......

Answer 3

查看Grails Best Practices

我认为这是一篇很好的解释良好做法的文章

Answer 4

从Java EE的角度来看：域类中根本没有逻辑。保持您的域类尽可能简单快捷。您的域模型是应用程序的核心，必须易于获取。

• 开发Grails用于依赖注入。所有驻留在域类中的逻辑都难以测试，并且太容易重构。
• 您无法与服务（DI）交换实施。
• 您无法轻松测试域类的代码。
• 您无法扩展系统，因为您的实施无法像服务一样进行池化。

我的建议：保持服务中的每一个逻辑。服务易于测试，易于重用，易于维护，易于重新配置。

特定于grails：如果更改域类，内存数据库将被终止，因此您将丢失测试数据，从而无法快速进行原型设计。