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

Question

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

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

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

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

Answer 1

Я бы порекомендовал заглянуть в API связывания и проверки Spring . Свяжите элементы формы с объектами, в которых нуждается сервисный уровень, и попросите контроллер передать их.

Я предпочитаю привязываться напрямую к бизнес-объектам, а не создавать DTO только ради веб-уровня. Я не люблю параллельные иерархии.

Answer 2

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

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

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