2010-11-08 3 views
2

Это веб-сайт ASP.NET MVC.Можно ли вызвать одну службу приложений из другой службы приложения?

В соответствии с проектированием, управляемым доменом, у нас есть сервисный уровень. Наши контроллеры просят классы сервисов приложений выполнять различные задачи, а затем направлять результаты в представления.

Бизнес-логика осуществляется классами обслуживания.

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

Таким образом, функциональность подписки на бюллетень тесно связана с регистрацией/модификацией учетной записи.

Однако, я чувствую, что было бы лучше иметь отдельный класс обслуживания NewsletterTasks, чтобы иметь дело с действиями по подписке/обновлению/отписанию.

Но этот класс не будет использоваться контроллером, но класс AccountTasks.

Таким образом, рабочий процесс будет выглядеть так:

-> request made to controller action 

-> controller calls AccountTasks 

-> AccountTasks creates a user acoount 

-> AccountTasks calls NewsletterTasks 

-> NewsletterTasks subscribes the user to the newsletter 

-> AccountTasks returns the result to the controller 

-> controller fetches the appropriate view and sends it to the client 

В качестве альтернативы, я бы контроллер назвать AccountTasks первым, затем с помощью результата вызовите NewsletterTasks. Но при таком подходе я чувствую, что контроллер слишком много знает о рабочем процессе, тогда как он должен просто передавать данные и результаты.

Задачи - это классы Application Service, проект основан на архитектуре S # arp с некоторыми изменениями, исходящими от Who Can Help Me, - который включает соглашения об именах для некоторых вещей.

Можно ли назвать NewsletterTasks от AccountTasks? Как бы вы это сделали?

ответ

3

Я был бы соблазн создать явную Регистрация пользователядомена службы:

-> request made to controller action 

-> controller calls UserRegistrationService 

-> UserRegistrationService calls AccountTasks 

-> AccountTasks creates a user acoount 

-> UserRegistrationService calls NewsletterTasks 

-> NewsletterTasks subscribes the user to the newsletter 

-> UserRegistrationService returns the result to the controller 

-> controller fetches the appropriate view and sends it to the client 

Что в свою очередь отвечает на ваш вопрос: Да, это нормально, чтобы вызвать другие службы из вашей службы

Надеюсь, что это поможет!

+0

Если я не представляю доменную службу, вы считаете, что все еще нормально, если AccountTasks вызывает NewsletterTasks (и имеет зависимость, мы используем DI)? Шимон ниже говорит, что он просто поместил его в контроллер, но я стараюсь оставить мои контроллеры глупыми, если можно, и делегировать любую бизнес-логику для обслуживания классов. Хотя я неохотно добавляю еще один слой, вся эта архитектура была для меня большим скачком. :) –

+0

Я склонен согласиться - поддержание «немых» контролеров «больше поддерживает DDD. Причина, по которой я бы ввел ** UserRegistrationService **, - сделать действие домена * явным *. Однако, если ваша команда говорит, что вызов AccountTasks-> NewsLetterTasks кажется более естественным, просто пойдите с этим. DDD - это упрощение понимания и упрощение изменений. –

-1

Я бы отстаивал дизайн, в котором контроллер называет обе задачи. Да, он несет дополнительную ответственность над контроллером, но, с другой стороны, он устраняет несколько неудобную ответственность AccountTasks для вызова NewsletterTasks. Кто-то еще должен решить, следует ли подписываться на конкретную учетную запись для информационного бюллетеня (в настоящее время все пользователи подписаны).

Я бы сделал это прагматично: всего за 2 задания я поставил бы ответственность за определение рабочего процесса в контроллере (возможно, в отдельном методе). Увеличивается количество задач, я бы определил специальный набор классов, целью которого является определение рабочих процессов.

Ваш дизайн выглядит несколько похожим на «Метод» Юваля Лоуи, а ваши задачи несколько похожи на его менеджеров, поэтому вы можете взглянуть на его paper.

Смежные вопросы