oop - 什么逻辑应该放在域类中，什么应该放在 Grails 中的服务中？

Question

我正在开发我的第一个 Grails 应用程序，其中涉及移植旧的 struts Web 应用程序。有很多现有的功能，当我移动东西时，我很难决定服务中应该包含哪些内容以及应该直接包含在模型中的内容？

来自主要是 Ruby on Rails 开发的背景，我强烈倾向于将几乎所有内容都放在与之相关的领域类中。但是，对于像我要移植的应用程序一样大的应用程序，某些类最终会变成成千上万行。

您如何决定应该在域中使用什么与应该在服务中使用什么？是否有任何既定的最佳实践？我做了一些环顾四周，但大多数人似乎只是承认这个问题。

Answer 1

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

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

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

1. 对于与视图呈现相关的内容，这些内容包含在标签库（或者可能是服务）中
2. 对于处理确定将什么发送到视图以及将其发送到哪个视图的事情，这些都在控制器（或者可能是服务）中
3. 对于与外部实体（即文件系统、队列等）对话的事物，它们进入服务

一般来说，我倾向于选择服务太多而不是把事情集中在一起。最后，一切都是关于什么对您最有意义，您如何看待代码以及您希望如何维护它。

但是，我要注意的一件事是，在您移植的内容中可能存在大量代码重复。由于 Grails 是在 Groovy 上构建的，并且可以使用更强大的编程方法（如闭包），您可能可以清理和简化大部分代码。

Answer 2

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

想想动态查找器，例如Book.findAllByName(). Grails 将它们注入到领域类中真是太好了。否则，它们必须被复制到每个域类，或者它们可以通过服务 ( dynamicFinderService.findAllByName('Book')-argh) 调用。

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

Answer 3

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

• Grails 是为依赖注入而开发的。驻留在域类中的所有逻辑都很难测试，也很容易重构。
• 您不能像与服务 (DI) 一样交换实现。
• 您无法轻松测试域类的代码。
• 你不能扩展你的系统，因为你的实现不能像服务一样被池化。

我的建议：在服务中保留所有逻辑。服务易于测试、易于重用、易于维护、易于重新配置。

特定于 grails：如果您更改域类，内存中的数据库将被杀死，因此您会丢失测试数据，这会阻止您进行快速原型设计。