我正在尝试确定这三个文件夹之间的区别以及我应该在其中放入的内容。
到目前为止，我一直在将类、接口以及与我的域类的结构（通过扩展或实现）直接相关的任何其他内容放入 src 文件夹中。除了默认情况下 Grails 控制器所做的之外，任何涉及额外事务逻辑的东西我都放在grails-app/services 文件夹中。最后，任何包含“帮助”方法的类（即比较各种事物、特殊字符串操作等）我都已放入 grails-app/utils 文件夹。
如果我错过了这些文件夹的用途的标记，请让我走上正确的道路。
【问题讨论】：
标签： model-view-controller grails
这非常接近。 grails-app/utils 用于 Codec 类——它的名字很奇怪，而且文档不足。我会将帮助类移回 src/groovy。
使用服务进行事务性工作很棒，但您也可以将服务用于非事务性方法。将static transactional = false 添加到具有不需要事务的实用方法的服务类中。请注意，控制器中没有事务性，因此您应该将所有持久性移至事务性服务。
src/groovy 辅助类中的静态实用程序方法和服务中的非事务性方法几乎是等价的，所以对我来说，决定采用哪条路线将归结为依赖关系。如果该类依赖于 Spring bean，则使其成为服务并通过依赖注入引用它们。否则就让它成为一个辅助类。
【讨论】：
withTransaction，所以我假设访问数据库的任何逻辑都是“事务性的”。现在看来我的假设是错误的。您能否通过定义什么是“交易”来澄清一下？
transaction 才能从数据库中获取关系数据（例如 author.books），否则会抛出异常（LazyInitializationException）。无论如何，我猜想静态变量之所以称为transactional 的原因确实是，如果它是真的，它会将完整的逻辑包含在一个事务中。
如果您发现自己将一个方法添加到依赖于非域类的域类中，请问问自己为什么这个方法可以放在服务中。这导致几乎每个域类都有相应的服务。
这使得将您的域类放入插件中变得更简单，这样您就可以通过使用相同的域模型构建多个应用程序来扩展功能，而不是创建一个无法维护的大泥球。也与Bob Martin大叔在《Lost Years of Architecture http://www.youtube.com/watch?v=WpkDN78P884987654321@》中描述的应用模型一致
鉴于您正在考虑建筑，最好阅读 Bob 叔叔和 Martin Fowler 的一些作品。
【讨论】：