门面使用和命名

Question

我的程序中的许多业务逻辑服务需要访问一组通用的非业务逻辑服务，例如电子邮件，打印，消息（消息框和提示）以及日志记录。我计划创建一个Facade来封装EmailService，PrintService，MessageService和LogService，这样每个业务逻辑服务只需要一个构造函数参数到facade类，而不是每个服务的四个参数。

所以而不是

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，以及我将来需要的其他一些非商业逻辑服务？

Answer 1

您所描述的内容不是facade，而是service locator（有关该模式的讨论，请参见Is ServiceLocator an anti-pattern?）。请注意，提出名称时出现问题是创建IKitchenSink界面的好兆头。

要成为外观，它必须以某种方式简化与服务的交互 - 可能有一个ArchveMessage调用将协调处理所有4个服务。

构造函数参数的数量通常无关紧要*因为无论如何都可能会创建具有依赖注入框架的此类对象。使用DI框架还可以通过提供记录所有方法调用的开始/结束/错误情况的方法来处理大多数“日志记录”责任。

_{*）大量注入的依赖项表明类的职责太多，需要从这个角度来看待。}