Использование фасада и наименование

Многочисленным службам бизнес-логики в моей программе требуется доступ к общему набору служб, не связанных с бизнес-логикой, таких как электронная почта, печать, обмен сообщениями (окна сообщений и подсказки) и ведение журнала. Я планирую создать фасад для инкапсуляции EmailService, PrintService, MessageService и LogService, чтобы каждой службе бизнес-логики требовался только один параметр конструктора для класса фасада вместо четырех параметров для каждой из служб.

Итак, вместо

public BusinessLogicService(IEmailService emailService, IPrintService printService, IMessageService messageService, ILogService logService)
{
   this.EmailService = emailService;
   this.LogService = logService;
   this.MessageService = messageService;
   this.PrintService = printService;
}

Я возьму это

public BusinessLogicService(ISomeFacade facade)
{
   this.SomeFacade = facade;
}

Мои вопросы:

  1. Это правильное использование шаблона фасада? Если нет, то как мне это сделать?

  2. Я предполагаю, что наличие стандартного набора служб, которые необходимы многим бизнес-службам, довольно распространено, поэтому существует ли стандартное соглашение об именах для такого рода фасадов, которое инкапсулирует EmailService, PrintingService, MessagingService, LoggingService и, возможно, некоторые другие нестандартные службы. сервисы бизнес-логики, которые мне понадобятся в будущем?


architecture c# facade
person Ben Rubin    schedule 31.10.2015    source источник
comment
выглядит как анти-шаблон локатора сервисов   -  person Dmitry Dovgopoly    schedule 31.10.2015
comment
Каким будет определение ISomeFacade в вашем случае?   -  person Yacoub Massad    schedule 01.11.2015

Ответы (1)


arrow_upward
3
arrow_downward

То, что вы описали, не является фасадом, а скорее локатор сервисов (см. обсуждение этого шаблона - Является ли ServiceLocator анти-шаблоном?). Обратите внимание, что проблема с названием — очень хороший признак создания IKitchenSink интерфейса.

Чтобы быть фасадным, он должен как-то упростить взаимодействие с сервисами — может быть, иметь один вызов ArchveMessage, который будет организовывать работу со всеми 4 сервисами.

Количество параметров конструктора, как правило, не имеет значения *, так как, вероятно, в любом случае такие объекты будут создаваться с помощью инфраструктуры внедрения зависимостей. Использование инфраструктуры DI также может взять на себя большую часть ответственности за «регистрацию», предоставляя способ регистрации случаев начала/конца/ошибки для всех вызовов метода.

*) большое количество внедренных зависимостей указывает на слишком много обязанностей класса и требует рассмотрения с этой точки зрения.

person Alexei Levenkov    schedule 31.10.2015