Take the 2-minute tour ×

In Grails controller actions, for validations, We use command objects. The problem is the number of CommandObject classes have exploded.

 def publish = { PublishCommand command ->
        if (command.hasErrors()) {
            return redirect(action: 'errors',params:params)
        //rest of the code

Class PublishCommand {
   long personId
   String name
   static constraints = {
        personId(nullable: false, blank: false)
        name(nullable: false, blank: false)


PublishCommand Class exists only for this databinding & validation purpose. Number of such classes have exploded, 1 created for each of the action of the application. Question is, Is there a way I can have this PublishCommand as innerClass? Or other ways where I don't have to create so many classes?

share|improve this question
As Joshua Moore said, definitely can add them as inner classes... I'm curious, what's causing the growth of command objects? I only ask because when I was first starting off in Grails I found myself using them more frequently because I wasn't taking full advantage of Grails' GSP form -> domain mapping capabilities. Now I find myself only using them for things like Searching where I don't have a @Validatable domain class to use. –  proflux Sep 29 '11 at 13:12
Some arguments can be made for using them to encapsulate the "message" being passed from a controller to a service. I say "message" in the sense of OOP where objects pass messages. By using a command object you are defining a contract between the controller and the service. Also this contract can be re-used by other interfaces beyond controllers (e.g. ESB). –  Joshua Moore Sep 29 '11 at 14:55
I was more curious about this particular case. The statement Number of such classes have exploded, 1 created for each of the action of the application. indicates to me that there may be some capabilities of Grails that may help fix the problem more fundamentally. –  proflux Sep 29 '11 at 16:53
@proflux We have lots of ajax requests coming in to various actions. They do not necessarily operate on a single domain. So to validate and also to have some standard 'message' (Like Joshua mentioned) sent between the controller and Service we started putting in command Objects. But as the application grew, The number of CommandObjects keeps growing. So I was thinking may be there is a better approach. –  Karthick AK Sep 29 '11 at 18:12

1 Answer 1

up vote 3 down vote accepted

It's a pretty common practice to place the command object classes within the same .groovy file as the controller (after the controller class). This will help cut down on the number of files you have to manage. Otherwise, you are following best practices (from what you have described).

share|improve this answer

Your Answer


