Цель команды формы Spring

Контроллер формы Spring (например, SimpleFormController или BaseCommandController) использует команды для передачи данных между HTML-формой и контроллером. Мой вопрос: является ли обычной практикой использование модели поддержки в качестве самой команды? Или обычно создается отдельная команда с соответствующими атрибутами в модели поддержки.

Моя проблема заключается в том, что для использования модели поддержки в качестве команды необходимы редакторы свойств для преобразования нестроковых атрибутов. Представьте себе модель данных со многими нестроковыми строго типизированными пользовательскими типами полей. При отправке формы редактор свойств выполняет преобразование до вызова валидатора. Если преобразование типа невозможно (ошибка пользовательского ввода), то валидатор никогда не сможет предоставить подробное сообщение об ошибке. Все, что отображается в HTML-форме, — это стандартное сообщение об ошибке. См. мой связанный вопрос Stackoverflow.

Альтернативой является создание отдельной команды, которая дублирует каждое поле в резервной модели, но в виде строки. Таким образом, валидатор может проверить строковое представление каждого поля. Затем onSubmit контроллера отвечает за преобразование текстовой команды в модель поддержки. Из моего исследования Spring это, по-видимому, предназначено для использования. Я не решаюсь пойти по этому пути из-за громоздкости, когда для каждой модели данных необходимо создавать отдельную команду. Кроме того, есть дополнительная работа, связанная с маршалированием между командой и моделью данных. Гораздо удобнее, чтобы форма напрямую редактировала модель поддержки и использовала редакторы свойств для преобразования. Тогда проблема в проверке.

Поэтому мне любопытно, как другие подходят к проблеме редактирования моделей на основе форм, содержащих настраиваемые нестроковые поля.


person Steve Kuo    schedule 09.04.2009    source источник


Ответы (2)



ИМХО, это сводится к тому, как вы хотите создавать классы домена. Я предпочитаю проектировать их довольно строго, даже не позволяя устанавливать несоответствующие значения и т. д. Это не очень хорошо сочетается с тем, как Spring обрабатывает привязку и проверку.

Поскольку я хочу избежать ослабления моей модели предметной области, я склонен использовать DTO в качестве командных объектов, поскольку обычно презентация все равно получает несколько иное представление об объектах предметной области. Классическим примером является класс домена пользователя, который содержит пароль. На уровне представления вы обычно хотите, чтобы фактический пользователь дважды ввел пароль и сравнил эти значения на этапе проверки. Только если они совпадают правильно, данные будут привязаны к классу предметной области.

Может привести к небольшим накладным расходам, но позволяет четко отделить уровень домена/приложения от представления.

person Oliver Drotbohm    schedule 30.04.2009