Архитектура MVC DTO/отображение/преобразование моделей

используя Spring MVC, мы обычно видим уровень контроллера, сервиса и репозитория. Слой репозитория использует модель сущностей, которая является сопоставлением один к одному с базой данных. Я подумал о том, чтобы последовать за ... --1-->

  1. должен ли слой обслуживания использовать ту же модель сущности?
  2. должен ли уровень обслуживания использовать отдельную модель домена? Если да, то отображение туда / сюда должно выполняться на уровне сервиса?
  3. должен ли уровень контроллера мы использовать ту же модель домена?
  4. должны Уровень контроллера использует отдельную модель DTO? Если да, то отображение туда / сюда должно выполняться в слое контроллера?
  5. есть ли простой способ сделать отображение не писать слишком длинный код? Я использовал Dozer несколько раз в прошлом.

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

8
dto entity java model spring

3 ответов

  1. да.
  2. нет. Служба должна работать с моделью сущности, возвращаемой объектом репозитория.
  3. нет. Контроллер должен использовать DTO. DTO должен содержать поля формы и аннотации проверки (если вы используете JSR303).
  4. да. DTOs используются на уровне контроллера. DTOs должен предоставить конструктор, который принимает модель сущности. Преобразование модели сущности в DTO выполняется в этом конструкторе. Тот же случай для модели сущности. Модель сущностей также должна предоставлять перегруженный конструктор, который принимает объект DTO в качестве аргумента. Преобразование DTO в Entity model должно произойти здесь.
  5. перегруженный конструктор DTO (Entity model as arg) и Entity model (DTO as arg) являются подробными.
5

1) да

2) нет

3,4) используйте entitys для вывода, но используйте CommandObjects и DTOs (но не сущности) для ввода. Это зависит от вашей архитектуры, но я не хочу, чтобы клиент маниуплатил каждое поле ваших сущностей, тогда вам нужно отделить объекты, используемые для сопоставления запросов (commandobjects) от ваших сущностей домена.

4

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

  • службы всегда работают с объектами, которые извлекаются и хранятся с помощью базы данных
  • службы всегда принимают DTOs или простые типы в качестве параметров и возвращают только DTOs. Почему? Потому что DTOs отделены из базы данных, и вы не сталкиваетесь с LazyInitializationException, и вам не придется использовать open-session-in-view anti-pattern.
  • подумайте о DTOs как единственной модели, разделяемой между службами и контроллерами
  • для сопоставления между сущностью и объектами DTO я рекомендую использовать ModelProjector. Это очень просто, постный и оставляет минимальный след

ModelProjector простые карты одной модели в другую путем сопоставления имен свойств. Если они не совпадают, вы можете сказать это с аннотацией, также можно отобразить сложные иерархии сущностей на "сплющенные" структуры данных с очень прямыми аннотациями. Классы сущностей остаются нетронутыми.

0