立面使用和命名

本文关键字： | 更新日期: 2023-09-27 18:20:13

我的程序中的许多业务逻辑服务需要访问一组常见的非业务逻辑服务，如电子邮件、打印、消息传递（消息框和提示）和日志记录。我计划创建一个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;
}

我的问题是：

这是立面图案的正确用法吗？如果没有，我该怎么做？
我认为拥有许多业务服务所需的标准服务集是很常见的，那么对于这种封装了EmailService、PrintingService、MessagingService、LoggingService，以及我未来可能需要的其他一些非业务逻辑服务的门面，是否有一个标准的命名约定？

立面使用和命名

您所描述的不是facade，而是服务定位器（有关该模式的讨论，请参阅-ServiceLocator是反模式吗？）。注意，名称出现问题是创建IKitchenSink接口的一个非常好的迹象。

要成为facade，它必须以某种方式简化与服务的交互——也许有一个ArchveMessage调用，它将协调处理所有4个服务。

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

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