Контроллер Grails, разработка командного объекта

В действиях контроллера Grails для проверки мы используем объекты команд. Проблема в том, что резко выросло количество классов CommandObject.

 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 существует только для этой цели привязки данных и проверки. Количество таких классов увеличилось, по 1 созданному для каждого действия приложения. Вопрос в том, есть ли способ использовать эту PublishCommand как innerClass? Или другие способы, где мне не нужно создавать так много классов?


controller grails command-objects
person Karthick AK    schedule 28.09.2011    source источник
comment
Как сказал Джошуа Мур, определенно можно добавить их как внутренние классы... Мне любопытно, что вызывает рост командных объектов? Я спрашиваю только потому, что, когда я впервые начал работать с Grails, я обнаружил, что использую их чаще, потому что я не в полной мере использовал возможности формы GSP Grails -> возможности сопоставления доменов. Теперь я обнаружил, что использую их только для таких вещей, как поиск, где у меня нет класса домена @Validatable для использования.   -  person proflux    schedule 29.09.2011
comment
Некоторые аргументы могут быть приведены для их использования для инкапсуляции сообщения, передаваемого от контроллера к службе. Я говорю сообщение в смысле ООП, когда объекты передают сообщения. Используя объект команды, вы определяете контракт между контроллером и службой. Также этот контракт может быть повторно использован другими интерфейсами за пределами контроллеров (например, ESB).   -  person Joshua Moore    schedule 29.09.2011
comment
Меня больше интересовал этот конкретный случай. Утверждение Number of such classes have exploded, 1 created for each of the action of the application. указывает мне на то, что в Grails могут быть некоторые возможности, которые могут помочь решить проблему более основательно.   -  person proflux    schedule 29.09.2011
comment
@proflux У нас есть много запросов ajax, поступающих на различные действия. Они не обязательно работают в одном домене. Поэтому для проверки, а также для отправки некоторого стандартного «сообщения» (как упоминал Джошуа) между контроллером и службой мы начали вводить объекты команды. Но по мере роста приложения количество объектов CommandObject продолжает расти. Поэтому я подумал, может быть, есть лучший подход.   -  person Karthick AK    schedule 29.09.2011

Ответы (1)


arrow_upward
3
arrow_downward

Довольно распространенной практикой является размещение классов объектов команд в том же файле .groovy, что и контроллер (после класса контроллера). Это поможет сократить количество файлов, которыми вы должны управлять. В противном случае вы следуете лучшим практикам (из того, что вы описали).

person Joshua Moore    schedule 29.09.2011