Question

Suppose I have a BaseForm which depends on an ILogger or IResourceManager or something like that. Currently it resolves the correct implementation of the required service using the service locator which I know is an anti-pattern.

• Is using the constructor injection the right way to resolve this kind of dependency?
• Do I have to register my BaseForm (and its’ derived types) in the container in order to create instances of them with resolved dependencies? Doesn’t that complicate everything?
• Is it bad to use a static factory wrapped around a service locator?
• Unit-testing aside, will I really be punished because of using service locator anti-pattern?

Sorry about asking many questions at once. I’ve read the following SO questions and many others but reading them only added to my confusion:

• How to use Dependency Injection and not Service Locator
• What’s the difference between the Dependency Injection and Service Locator patterns?
• How to avoid Service Locator Anti-Pattern?

Answer 1

If possible, you should always go with dependency injection, since it has a few clear strength. With UI technologies however, it is not always possible to use dependency injection, since some UI technologies (in .NET space, Win Forms and Web Forms, for instance) only allow your UI classes (forms, pages, controls, etc) to have a default constructor. In that case you will have to fall back to something else, which is service locator.

In that case I can give you the following advice:

• Only fall back to Service Locator for UI classes that can’t be created by your container using dependency injection, and for stuff that you aren’t unit testing anyway.
• Try to implement as less logic as possible in those UI classes (as Humble objects with only view related stuff). This allows you to unit test as much as possible.
• Wrap the container around a static method to hide the container from the rest of the application. Make sure that a call to this static method fails, when the dependency cannot be resolved.
• Resolve all dependencies in the (default) constructor of that type. This allows the application to fail fast when one of its dependencies cannot be resolved when that type is created, instead of later on when some button is clicked.
• Check during app start-up (or using a unit test), if all those UI types can be created. This saves you from having to go through the whole application (by opening all forms) to see if there is an error in the DI configuration.
• When types cannot be built by the container, there is no reason to register them in the container. If they can be created by the container (such as with ASP.NET MVC Controller classes), it can be useful to register them explicitly, because some containers allow you to verify the configuration up front, which will detect configuration errors in those types right away.

Besides unit testing, there are two other important arguments against the use of the Service Locator, which are given by Mark Seemann in his famous blog post Service Locator is an Anti-Pattern:

• Service Locator “hides a class’ dependencies, causing run-time errors instead of compile-time errors”
• Service Locator is “making the code more difficult to maintain”