我读到服务用于跨多个域类的更新。但是，我有命令类，并且我想知道将事务更新的逻辑放入命令类是否存在重大缺陷（或打破了Grails范例）。喜欢的东西：在Grails中使用命令对象进行更新
class ObjectOneCommand {
...
def save() {
objectOneInstance.save()
objectTwoInstance.save()
}
}
并在控制器
ObjectOne.withTransaction { transactionStatus ->
objectOneCommand.save()
}
我只是新的Grails，但是从我的理解，命令对象基本上是一个聪明的方式做数据绑定传入参数，以便您可以进一步验证它们，或者对它们进行一些处理。本质上它是从领域类本身进行领域模型约束检查，并在将属性传递给领域对象以进行持久性（通常通过服务）之前对属性进行按摩。
因此命令对象（对我来说）不是域对象上的事务业务逻辑的地方。
此外，由于可以将服务注入其他类，因此可以以这种方式在服务中重用业务逻辑。如果将逻辑放置在命令对象中，依赖注入不是您的选择，您可能会在不同的命令对象之间重复逻辑。
因此，既然你可以注入服务到你的命令类中，所以我想这对你来说可能是合理的。
一般来说，这违背了Grails范式，也是大多数MVC范式。正如Ciaran指出的那样，您在Command和Controller类中放置的逻辑不可重用。您将无法从其他控制器（很容易）调用它，因此您可能最终会一次又一次地重写它。在你的服务中做一个方法来做这个持久化，使用def transactional = true会好很多。
查看此链接，其中作者David Dawson建议使用命令对象为输入请求建模并在整个请求期间保持状态。我不确定这是一个好还是坏的想法，但它与你所描述的非常相似。