Facade 的使用和命名

Question

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

所以

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;
}

我的问题是：

这是门面模式的正确用法吗？如果没有，我应该怎么做？
我假设拥有许多业务服务所需的一组标准服务是很常见的，那么是否有针对封装 EmailService、PrintingService、 MessagingService、LoggingService，以及我将来可能需要的其他一些非业务逻辑服务？

Answer 1

您描述的不是 facade but rather service locator (see for discussion on that pattern - Is ServiceLocator an anti-pattern?)。请注意，名称出现问题是创建 IKitchenSink 接口的一个很好的标志。

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

构造函数参数的数量通常无关紧要*，因为无论如何都可能会使用依赖注入框架创建此类对象。使用 DI 框架还可以通过提供一种方法来记录所有方法调用的 start/end/error 个案例，从而承担大部分 "logging" 责任。

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

Facade 的使用和命名

Facade usage and naming

c#

architecture

facade