Как использовать DTO в шаблоне Controller, Service и Repository - PullRequest
Новая
       18

Как использовать DTO в шаблоне Controller, Service и Repository

0 голосов
/ 19 апреля 2020

Я следую шаблону «Контроллер, Сервис и Репозиторий» и мне просто интересно, откуда в это вступают DTO.

Должен ли контроллер получать только DTO? Насколько я понимаю, вы не хотели бы, чтобы внешний мир знал о базовой модели предметной области?

Должно ли преобразование из доменной модели в DTO происходить на уровне контроллера или службы?

Ответы [ 4 ]

0 голосов
/ 19 апреля 2020

В современном программировании с использованием Spring MVC и интерактивных пользовательских интерфейсов веб-приложение на самом деле имеет 4 слоя:

  • Уровень пользовательского интерфейса (веб-браузер, JavaScript)

  • MVC Контроллер, т.е. компоненты пружины, отмеченные @Controller

  • Сервисный уровень, т.е. компоненты пружины, обозначенные @Service

  • Уровень доступа к данным, т. Е. Компоненты Spring, помеченные @Repository

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

Между уровнями должны использоваться только DTO, и они не обязательно одинаковы, например, сервисный уровень может применять бизнес-логику c к DTO, полученным из доступа к данным. Уровень, поэтому DTO API Service Layer отличается от API уровня доступа к данным. Аналогичным образом, контроллер может переупорядочить данные, чтобы подготовить их к представлению (группирование, сводка и т. Д.), Поэтому данные, отправляемые в веб-браузер, отличаются от данных, полученных с уровня обслуживания.

При полном абстракция, API уровня доступа к данным не должен отражать технологию доступа к данным, то есть, использует ли он JDB C, JPA, No SQL, веб-сервис или какие-либо другие средства хранения / извлечения данных. Это означает, что классы Entity не должны выходить за пределы уровня доступа к данным.

Большинству проектов не нужен этот уровень абстракции, поэтому DTO обычно являются классом Entity и передают все путь от уровня доступа к данным до контроллера, где он используется либо представлением, либо отправляется в веб-браузер в кодировке JSON.

Это зависит от размера и сложности проекта. , Чем больше проект, тем важнее сделать каждый слой максимально абстрактным / автономным.

0 голосов
/ 19 апреля 2020

Правильный путь будет «Контроллер -> Сервис -> Реализация -> Репозиторий»

Ваш уровень репозитория может вернуть базовую модель, которая может быть преобразована в ваш DTO при получении уровнем реализации.

0 голосов
/ 19 апреля 2020

Существуют разные схемы, которым следуют разные организации. Это зависит от того, какой шаблон вы используете. Исходя из своего личного опыта, я следую нижеприведенной диаграмме архитектуры.

enter image description here

Согласно приведенной выше диаграмме, DTO для Entity Conversation и наоборот будет внутри службы только слой.

0 голосов
/ 19 апреля 2020

Упрощенный ответ, вероятно, будет следующим: DTO (если вам нужно, см. Ниже) - это то, что позволяет вам передавать определенную c информацию куда-то еще. Это задача Контроллера / Адаптера / Хранилища / как бы вы это ни называли. Задача адаптера - взять информацию из внешнего мира (за пределами вашей системы) и преобразовать эту информацию в соответствующую модель домена, чтобы сервисная логика c могла работать с ней.

И, с моей точки зрения, это также относится к репозиториям: репозиторий сохраняет данные во внешней системе (например, в базе данных или даже в другой службе REST) ​​и возвращает их по запросу. Для этого, вероятно, потребуется преобразовать модель предметной области в упрощенный DTO, чтобы ее можно было сохранить в целевой системе.

Идея адаптеров заключается в том, что бизнес-логике c не нужно знать как преобразовать объект, который будет представлен или передан через протокол REST / SOAP / MySQL / .... Это задача адаптера. Поэтому: DTO должны оставаться в адаптере, если они вам нужны.

Действительно ли вам нужны DTO?

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

Если вы, с другой стороны, используете десериализатор для своих объектов (например, Джексон для JSON или что-то в этом роде), вам может потребоваться DTO, поскольку для этих инструментов иногда требуются особые требования, чтобы возможность сериализации и десериализации ваших данных в объект. Здесь вам может потребоваться перейти к использованию DTO, прежде чем вы сможете преобразовать его в объект домена или наоборот.

Кстати: на этот вопрос также неплохо ответили на softwareengineering.stackexchange. ком

...