Правильный ли дизайн Репозитория-> Сервис-> Контроллер? - PullRequest
Новая
       19

Правильный ли дизайн Репозитория-> Сервис-> Контроллер?

0 голосов
/ 21 января 2020

Мне интересно, использую ли я правильную архитектуру в своем приложении.

После вызова конечной точки в моем API я в настоящее время выполняю следующий поток: Api.EmployeeController.Update(Api.EmployeeUpdateDto) => Services.EmployeeService.Update(Service.EmployeeUpdateDto) => Data.EmployeeRepository.Update(Entities.Employee) => Data.EfDbContext.Employees.Update(Entities.Employee)

Чтобы пояснить еще кое-что, моя конечная точка API принимает Api.EmployeeUpdateDto, в контроллере она отображается на Services.EmployeeUpdateDto и передается на Services.EmployeeService.Update(). В Services.EmployeeService.Update() он извлекает фактическую сущность БД по Id и обновляет ее значения, после чего она передается в EmployeeRepository.Update(), который, в свою очередь, вызывает базовый контекст БД EF.

По какой-то причине моя интуиция говорит мне, что это сложно слишком много слоев, я что-то упустил?

Ответы [ 2 ]

0 голосов
/ 22 января 2020

Хорошо. Это где шаги:

  1. Api.EmployeeController.Update (Api.EmployeeUpdateDto)
  2. Services.EmployeeService.Update (Service.EmployeeUpdateDto)
  3. Data.EmployRe. Обновление (Entities.Employee)
  4. Data.EfDbContext.Employees.Update (Entities.Employee)

Прежде всего. Хорошо, что у вас есть EmployeeUpdateDto, поскольку вы обычно не обновляете точно те же поля, что и при создании нового объекта. Однако обычно я использую подход, основанный на более сложных задачах, например LockUserDTO, RenameUserDTO et c,

В DDD есть два типа услуг. Сервисы приложений и доменные сервисы. Службы приложений действуют как фасад для защиты вашего домена, тогда как службы домена используются для координации работы между несколькими объектами.

Service.EmployeeUpdateDto на самом деле не добавляет никакой ценности. Если API dto изменяется, или если объект изменяется, он все еще должен быть обновлен. Таким образом, это не обеспечивает никакой дополнительной абстракции против только наличия API dto. Поэтому я бы удалил его и позволил сервису приложений напрямую использовать API dto.

  1. Api.EmployeeController.Update (Api.EmployeeUpdateDto)
  2. Services.EmployeeService.Update (Api.EmployeeUpdateDto )
  3. Data.EmployeeRepository.Update (Entities.Employee)
  4. Data.EfDbContext.Employees.Update (Entities.Employee)

Обычно я не использую сущность домена как сущность БД, так как она часто требует компромиссов в проекте, чтобы ORM мог сохранять ее должным образом. Помните, доменные сущности - ваше самое драгоценное сокровище. Единственное, что должно влиять на их дизайн - это домен.

0 голосов
/ 21 января 2020

Да, вы все усложняете, но это немного неуловимо. Хитрость заключается в том, что ваш слой между репозиторием и вашим сервисным уровнем должен передаваться в EmployeeUpdateDTO и не должен ничего знать о сущности. Сущность должна содержаться внутри вашего слоя репозитория.

Я не совсем уверен, почему у вас есть EmployeeUpdateDTO, а не просто EmployeeDTO, я просто упростил бы это до EmployeeDTO, после чего у вас есть реальный объект домена.

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

Api.EmployeeController.Update (Api.EmployeeUpdateDto) => Services.EmployeeService.Update (Service.EmployeeDto) => Data.EmployeeRepository.Update (Service.EmployeeDto) => Data.EpDate (). Entities.Employee)

...