c# - Facade 的使用和命名

Question

我的程序中的许多业务逻辑服务需要访问一组通用的非业务逻辑服务，例如电子邮件、打印、消息传递(消息框和提示)和日志记录。我计划创建一个外观来封装 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、以及我将来可能需要的其他一些非业务逻辑服务？

Answer 1

您描述的不是 facade而是service locator (有关该模式的讨论，请参阅 - Is ServiceLocator an anti-pattern?)。请注意，名称出现问题是创建 IKitchenSink 接口(interface)的良好标志。

作为外观，它必须以某种方式简化与服务的交互 - 也许有一个 ArchveMessage 调用将协调所有 4 个服务的工作。

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

---

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