Нужно ли иметь класс домена / сущности, если все мои бизнес-логики c находятся в классе обслуживания? - PullRequest
2 голосов
/ 31 января 2020

Я работаю над приложением REST API, которое не имеет постоянного уровня. Я получаю запрос, делаю логику преобразования c и возвращаю ответ.

  • Нужен ли мне еще слой домена / сущности между моим представлением dto и классом обслуживания бизнес-логики c?
  • Если да, в чем преимущество добавления доменного слоя?

  • Следует ли мне использовать Mapstruct для обработки сложных карт отображения c для замены части журнала преобразования c?

Ответы [ 2 ]

1 голос
/ 31 января 2020

Мне все еще нужен слой домена / сущности между моим представлением dto и бизнес-логи c класс обслуживания?

Нет сущности, сущность, предназначенная для сохранения, имеет нормальный класс домена и класс DTO, который фактически предназначен для передачи данных ie реквизит / ответ, домен предназначен для некоторой бизнес-логики уровня c, в DTO мы можем поместить только запрос / ответ, но если есть лог c для обработки этого запроса и иметь один домен для объектной модели для выполнения бизнес-процесса

Если так, в чем преимущество добавления слоя домена?

Объекты домена (DO) (и классы, из которых они получены) реализуют бизнес-логику c, так как они расположены только в слое / домене бизнес-логики c (основное значение остается тем же, даже если термины разные).

Должен ли я использовать Mapstruct для обработки сложных карт отображения c, чтобы заменить часть логики преобразования c?

Мы можем использовать ModelMapper для преобразования из доменного объекта в любой другой объект или есть Dozzer Mapper, также мы можем использовать этот libaray

Request DTO ->Controller Layer --> Service Layer --Uses bussiness logic --> Domain Object --Convert to Response DTO --> Response DTO
0 голосов
/ 31 января 2020

Хороший дизайн, если в приложении есть слои View Layer, Business Layer и Backend. Нам не нужно использовать сущности в качестве POJO, вместо этого у нас должны быть отдельные служебные классы для преобразования данных сущностей в модели, а модели в сущности. Это отделит ваш бизнес-уровень от уровня данных. Если вы вносите какие-либо изменения в сущности, которые никак не повлияют на ваш бизнес-уровень, и наоборот.

Надеюсь, что это прояснит понимание.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...