Команда команды «Назначение весны»

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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