Взаимозависимость уровня обслуживания

Question

Я занимаюсь разработкой приложения asp.net mvc, которое использует сервисный уровень. Что если у нас есть сервис, который зависит от другого сервиса? Например, предположим, что у нас есть следующая модель:

class UserService : IUserService
{
    //implementation requires IEmailService
}    

Конечно, конкретная реализация EmailService может быть внедрена в конструктор UserService, но, насколько я понимаю, сервисный уровень должен быть посредником между пользовательским интерфейсом и моделью домена, это как фасад. Я бы определил другой уровень таким образом, чтобы UserService зависел от IUserModule и IEmailModule, и таким образом мы могли бы разорвать зависимость между службами, службы зависят от более низкого уровня (в моем случае - уровень модуля). Это правильный подход?

Answer 1

Внутри общей архитектуры DDD вы найдете два вида служб Доменные службы (чьи бизнес-операции координируются между объектами) и Прикладные службы (чьи зависят от служб Домена и содержат задачи, связанные с приложением, а не с бизнес-логикой Например, экспорт в pdf - это задача приложения. Применение скидки - это задача бизнес-логики.)

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

Answer 2

Конечно, конкретную реализацию EmailService можно внедрить в конструктор UserService, но, на мой взгляд, сервисный уровень должен быть посредником между пользовательским интерфейсом и моделью домена.

Что ж, это контрактмежду сторонами, не обязательно UI и Domain Model, но обычно.

это как фасад.

Да, хороший сервис имеет красивый фасад, также учитывающий производительность.

таким образом, мы можем разорвать зависимость между сервисами, сервисы зависят от нижнего уровня (в моем случае модуль слоя).Это правильный подход?

Что для вас значит модуль?IEmailService - это сервис или модуль для вас?Кажется правильным создать Фасад в вашем случае для вашего обслуживания.Но вы предоставляете мало информации о вашей системе, ваших намерениях и ваших архитектурных задачах / приоритетах.

Answer 3

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