Grails：服务 VS Groovy 类
文档说：
Grails 团队不鼓励 嵌入核心应用逻辑 内部控制器，因为它没有 促进再利用和干净分离 的担忧。
我在 src/groovy 文件夹中有一个 API 控制器和一些 Groovy 类。这些类只是实现我的应用程序逻辑，因此 API 控制器中的操作以这种方式工作：
//index page
def index = {
render new IndexApi().index(params) as JSON
}
我很好奇 - 是否有任何理由将我的应用程序逻辑从普通的 groovy 类移动到服务中？
Documentation says:
The Grails team discourages the
embedding of core application logic
inside controllers, as it does not
promote re-use and a clean separation
of concerns.
I have one API controller and a few Groovy classes in src/groovy folder. Those classes just implements my application logic so actions in API controller works in this way:
//index page
def index = {
render new IndexApi().index(params) as JSON
}
I'm curious - is there any reason to move my application logic from plain groovy classes into services ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
事实上，服务不仅仅是交易。服务非常适合零配置可注入单例组件，并且可以重新加载它们而无需重新启动整个 grails 环境，并且它们可以作为人工制品被发现，从而通过远程插件自动公开。
Actually services are not just about transactions. Services are great for zero-config injectable singleton components, and they can can be reloaded without restarting the whole grails environment, AND they can be discovered as artefacts and hence automatically exposed with remoting plugins.
如果您想要事务行为，您应该将逻辑放入服务中。否则您就必须自己处理它，这不符合使用 Grails 的精神。
由于我自己不是 Grails 专家，所以我将“非事务性”类放在服务层之外，例如构建器类、帮助程序以及其他非事务性但从服务层使用的逻辑。
If you want transactional behavior you should put your logic in the Services. Else you would have to take care about it yourself, which is not in the spirit of using Grails.
Being not a grails expert myself, I put my 'not transactional' classes outside the service layer, like builder classes, helpers, and other logic that is not transactional but used from the service layer.
原因有三个：
它使控制器变得更小 ->更容易理解和维护
它使您的逻辑更易于测试。
您确实不想手动管理您的交易。
如果您将所有内容放入控制器中，则需要创建 Web 运行时才能运行任何测试。如果您的逻辑位于外部，您可以从 HTTP 请求和所有其他来源复制所需的数据，然后只需调用代码即可。因此逻辑不依赖于 HTTP 会话、请求或任何您不希望的其他内容。
例如，要测试 JSP，您需要 HTTPRequest。对于请求，您需要一个 HTTPSession 和一个 JSPWriter。这些需要会话上下文。因此，为了能够运行单个测试，您需要设置并初始化一大堆类。所有这些都是接口，并且实现都是私有的。因此您必须自己实现实际的方法（全部 300 个）。你最好把这件事做好，否则你的测试将无法测试你想要的结果。
There are three reasons:
It makes the controller smaller -> easier to understand and maintain
It makes you logic easier to test.
You really don't want to manage your transactions manually.
If you would put everything in the controller, you would need to create the Web runtime to be able to run any test. If your logic is outside, you can copy the data you need from the HTTP request and all the other sources and just call the code. So the logic isn't depending on HTTP sessions, requests or anything else you don't want to.
For example, to test JSPs, you need a HTTPRequest. For a request, you need a HTTPSession and a JSPWriter. Those need a session context. So just to be able to run a single test, you need to set up and initialize a whole bunch of classes. And all of those are interfaces and the implementations are private. So you must implement the actual methods (all 300 of them) yourself. And you better get this right or your tests won't test what you want.