Tiwari reminds you:
If the command object is defined in the same source file as the controller that is using it, Grails will automatically mark it as Validateable. It is not required that command object classes be validateable.
This post shows the @Validatable annotation. In Grails 3 you will implement the Validateable trait instead.
My colleague @mattdmoss published recently a new Grails Guide around the use of Command Objects to handle form data. He explains how to use domain classes and regular POGOs as command objects.
@epragt shows you how to use the mockCommandObject in Grails 2.x to tests your Command Objects.
Really thought-provoking talk by @davidthecoder. He encourages the use of commands objects to model Application Domains. Use Command objects to have state, identity and behaviour. First 15 minutes of the video are pure gold.
I agree with two of his beefs:
- Domain classes should probably be named persistence classes.
- With singleton scoped services and controllers, thus stateless artifacts, Grails appears to have functional envy.
A companion post to the previous video by @davidthecoder:
the responsibility to model the queries and commands into the system, which I have handled with Command Objects.
or the best command object quote ever:
Command Objects are a powerful and cheap way to obtain that fuller model and give added benefits such as parameter validation, data binding, type conversion and dependency injection.
If you are working with Grails 2.x versions, binding lists with command objects may be tricky. Groovy's .withLazyDefault method , which we talked about in the first link of this issue, helps you out as shown by @mscharhag
Interesting Post which shows how to create a revalidate() method in every command object in a Grails 2 application. Imagine you need to do data changes after the initial binding and validate again. This approach may help you.