2

我读到服务用于跨多个域类的更新。但是，我有命令类，我想知道将进行事务更新的逻辑放入命令类是否有明显的缺点（或破坏 Grails 范式）。就像是：

class ObjectOneCommand {
...
    def save() {
        objectOneInstance.save()
        objectTwoInstance.save()
    }
}

在控制器中

ObjectOne.withTransaction { transactionStatus ->
    objectOneCommand.save()
}
4

3 回答 3

4

我只是 Grails 的新手，但据我了解，命令对象基本上是一种对传入参数进行数据绑定的聪明方法，以便您可以进一步验证它们，或者对它们进行一些处理。本质上，它从域类本身进行域模型约束检查，并在将属性传递给域对象以进行持久性（通常通过服务）之前对其进行按摩。

因此命令对象（无论如何对我来说）不是域对象上事务业务逻辑的地方。

此外，由于可以将服务注入其他类，因此您可以通过这种方式重用服务中的业务逻辑。如果您将逻辑放在命令对象中，则依赖注入不是您的选择，您最终可能会在不同的命令对象之间复制逻辑。

因此，由于您可以将服务注入您的命令类，所以我想您沿着这条路线走下去可能是有意义的。

于 2011-03-01T17:07:33.417 回答
0

一般来说，这与 Grails 范式以及大多数 MVC 范式背道而驰。正如 Ciaran 指出的那样，您放入 Command 和 Controller 类的逻辑是不可重用的。您将无法（轻松地）从其他控制器调用它，因此您最终可能会一次又一次地重写它。在您的服务中创建一个方法来实现这种持久性def transactional = true会更好。

于 2011-03-01T23:27:04.503 回答
0

查看此链接，作者 David Dawson 建议使用命令对象对传入请求进行建模并在整个请求期间保持状态。我不确定这是个好主意还是坏主意，但这与您所描述的非常相似。

http://www.simplicityitself.com/article/all-hail-command

于 2013-11-25T20:02:44.890 回答