Spring MVC: уровень служб должен возвращать операцию определенный DTO?
В моем Spring приложение MVC я использую DTO на уровне представления для инкапсуляции модели предметной области на уровне служб. DTO используется в качестве пружинных объектов поддержки формы.
следовательно мои сервисы выглядят примерно так:
userService.storeUser(NewUserRequestDTO req);
Уровень служб переведет DTO-> Объект области и делает остальную часть работы.
Теперь моя проблема состоит в том, что, когда я хочу получить DTO от сервиса для выполнения, говорят, что Обновление или Дисплей, я, может казаться, не нахожу лучший способ сделать это затем, чтобы иметь несколько методов для поиска, которые возвращают другой DTO как...
EditUserRequestDTO userService.loadUserForEdit(int id);
DisplayUserDTO userService.loadUserForDisplay(int id);
но что-то не чувствует себя хорошо об этом подходе. Возможно, сервис не должен возвращать вещи как EditUserRequestDTO, и контроллер должен быть ответственен за сборку requestDTO от специализированного объекта формы и наоборот.
Причина действительно имеет отдельный DTO, то, что DisplayUserDTO со строгим контролем типов, чтобы быть только для чтения и также существует много свойств пользователя, которые являются объектами от справочной таблицы в дб (как город и состояние), таким образом, DisplayUserDTO имел бы строковое описание свойств, в то время как EditUserRequestDTO будет иметь идентификатор, который поддержит избранные выпадающие списки в формах.
Что Вы думаете?
спасибо
1 ответ
Мне нравятся урезанные экранные объекты. Это более эффективно, чем создание всего объекта домена только для отображения нескольких его полей. Я использовал похожую схему с одним отличием. Вместо использования редактируемой версии DTO я просто использовал объект домена в представлении. Это значительно сократило работу по копированию данных между объектами. Я не решил, хочу ли я сделать это сейчас, поскольку я использую аннотации для JPA и Bean Validation Framework, и смешивание аннотаций выглядит беспорядочно.Но я не люблю использовать DTO с единственной целью - держать объекты домена вне уровня MVC. Похоже, много работы не приносит большой пользы. Также было бы полезно прочитать взгляд Фаулера на анемичные объекты . Возможно, это не совсем так, но об этом стоит подумать.
1-е изменение: ответ на комментарий ниже.
Да, мне нравится использовать фактические объекты домена для всех страниц, которые работают с одним объектом одновременно: редактировать, просматривать, создавать и т. Д.
Вы сказали, что берете существующий объект и копируете поля вам нужно в DTO, а затем передать DTO как часть модели вашему шаблонизатору для страницы просмотра (или наоборот для создания). Что это вам дает? Ссылка на DTO весит не меньше, чем ссылка на полный объект домена, и вам нужно выполнить копирование всех дополнительных атрибутов. Нет правила, согласно которому ваш шаблонизатор должен использовать все методы вашего объекта.
Я бы использовал небольшой частичный объект домена, если он повышает эффективность (нет графов отношений для построения), особенно для результатов поиска. Но если объект уже существует, не беспокойтесь о том, насколько он большой или сложный, когда вы вставляете его в модель для рендеринга страницы. Он не перемещает объект в памяти. Это не вызывает нагрузки на движок шаблонов. Он просто получает доступ к нужным методам и игнорирует остальные.
2-е изменение: Хорошее замечание. Бывают ситуации, когда вам может понадобиться ограниченный набор свойств, доступных для представления (например, разные внешние и внутренние разработчики). Я должен прочитать более внимательно, прежде чем отвечать.Если бы я собирался делать то, что вы хотите, я бы, вероятно, поместил отдельные методы для User (или любого другого класса) формы forEdit () и forDisplay (). Таким образом, вы можете просто получить User из уровня сервиса и сказать User, чтобы он предоставил вам свои ограниченные копии для использования. Думаю, возможно, именно этого я и добивался в комментарии к анемичным объектам.