I read that services are used for updates across multiple domain classes. However, I have command classes, and I would like to know whether putting the logic that makes transactional updates into a command class has a significant downside (or breaks the Grails paradigm). Something like:
class ObjectOneCommand {
...
def save() {
objectOneInstance.save()
objectTwoInstance.save()
}
}
And in a controller
ObjectOne.withTransaction { transactionStatus ->
objectOneCommand.save()
}
I'm only new to Grails, but from what I understand, the command object is basically a clever way to do data-binding on incoming parameters so that you can validate them further, or perhaps do some processing on them. Essentially it's taking the domain model constraint checks from the domain class itself and massaging properties before they are passed to a domain object for persistence (often via a service).
Thus command objects (for me anyway) are not a place for transaction business logic on domain objects.
Also since services can be injected into other classes, you can reuse business logic in services in this way. If you place your logic in command objects, dependency injection is not an option for you and you may end up duplicating logic amongst different command objects.
So since you can inject services into your command classes, so I guess it might make sense for you to go down that route.