On the other hand, this may not be the case. What happens in a production application? The IOrderCollector interface may already be registered with the Service Locator because it is already in use by other components, in which case it will work without a hitch. It certainly compiled fine, but broke one of my unit tests. This is easily done, or is it?įrom a pure mechanistic point of view, that was easy - we simply added a new call to Locator.Resolve and invoke IOrderCollector.Collect. Let's say that we need to expand the behavior of OrderProcessor to also invoke the IOrderCollector.Collect method. While this use of Service Locator is problematic from the consumer's point of view, what seems easy soon becomes an issue for the maintenance developer as well. What is even more annoying is that because the Locator's internal store is static, we need to invoke the Reset method after each unit test, but granted: that is mainly a unit testing issue.Īll in all, however, we can't reasonably claim that this sort of API provides a positive developer experience. Locator.Register(() => validatorStub.Object) ValidatorStub.Setup(v => v.Validate(order)).Returns( false) In a unit test test, this can be done like this:
#Bind to blueservice failed code#
This is not only surprising, it may be quite baffling if we don't have access to the source code.īy perusing the source code (or using Reflector) or consulting the documentation (ick!) we may finally discover that we need to register an IOrderValidator instance with Locator (a completely unrelated static class) before this will work. That means I can simply create a new instance of it and invoke the Process method right away:Īlas, running this code surprisingly throws a KeyNotFoundException because the IOrderValidator was never registered with Locator. Okay, so the class has a default constructor. This is what we get from IntelliSense in Visual Studio: We didn't write it ourselves, it was given to us in an assembly by a third party, and we have yet to look at it in Reflector. Let's assume for a moment that we are simply consumers of the OrderProcessor class.
Given that, then what could be the problem? This is flexible and extensible, and it even supports replacing services with Test Doubles, as we will see shortly. A ‘real' Service Locator implementation would be much more advanced than this, but this example captures the gist of it. We can configure the Locator using the Register method. Public static void Register( Func resolver) The Service Locator is used as a replacement for the new operator. Public class OrderProcessor : IOrderProcessor Here's an example using a static Service Locator: To process an order, the OrderProcessor must validate the order and ship it if valid.
In short, the problem with Service Locator is that it hides a class' dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.Īs an example, let's pick a hot topic in DI these days: an OrderProcessor.
No, it's actually an anti-pattern and should be avoided. Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right?
0 kommentar(er)
