程序中的许多业务逻辑服务都需要访问一组通用的非业务逻辑服务,例如电子邮件,打印,消息传递(消息框和提示)和日志记录.我计划创建一个外观来封装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;
}

我的问题是：

>这是门面图案的正确用法吗？如果没有,我应该怎么做？
>我认为拥有很多业务服务所需的一组标准服务是很普遍的,因此,针对这种外观的标准命名约定是否存在,其中封装了EmailService,PrintingService,MessagingService,LoggingService以及其他可能的非我将来需要的业务逻辑服务？

解决方法:

您所描述的不是facade,而是service locator(有关该模式的讨论,请参见Is ServiceLocator an anti-pattern?).请注意,输入名称的麻烦是创建IKitchenSink接口的好兆头.

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

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

*)大量注入的依赖项表明该类的职责过多,因此需要从这一角度来考虑.