Search code examples
c#architecturefacade

Facade usage and naming


Numerous business logic services within my program need access to a common set of non-business logic services, such as email, printing, messaging (message boxes and prompts), and logging. I am planning on creating a facade to encapsulate EmailService, PrintService, MessageService, and LogService so that each business logic service just needs one constructor parameter to the facade class, instead of four parameters to each of the services.

So instead of

public BusinessLogicService(IEmailService emailService, IPrintService printService, IMessageService messageService, ILogService logService)
{
   this.EmailService = emailService;
   this.LogService = logService;
   this.MessageService = messageService;
   this.PrintService = printService;
}

I'll have this

public BusinessLogicService(ISomeFacade facade)
{
   this.SomeFacade = facade;
}

My questions are:

  1. Is this the correct usage of the facade pattern? If not, how should I be doing this?

  2. I assume that having a standard set of services that are needed by a lot of business services is pretty common, so is there a standard naming convention for this sort of facade that encapsulates EmailService, PrintingService, MessagingService, LoggingService, and possibly some other non-business logic services that I need in the future?


Solution

  • What you've described is not facade but rather service locator (see for discussion on that pattern - Is ServiceLocator an anti-pattern?). Note that trouble coming up with the name is very good sign of creating IKitchenSink interface.

    To be facade it must somehow simplify interaction with the services - maybe have one ArchveMessage call that will orchestrate working with all 4 services.

    Number of constructor parameters generally does not matter* since one likely will be creating such objects with dependency injection framework anyway. Using DI framework may also take care of most "logging" responsibility by providing a way to log start/end/error cases for all method calls.


    *) large number of injected dependencies indicate too many responsibilities of the class and need to be looked at from that point of view.