The Common Service Locator library
Engineering
Mark Pollack
October 03, 2008
The CommonServiceLocator project was released this week on CodePlex with the general idea of providing an IoC container agnostic API for resolving dependencies using Service Location. Erich Eichinger from SpringSource contributed the Spring.NET implementation, thanks Erich!
Here is the API so you get the basic idea
public interface IServiceLocator : System.IServiceProvider {
object GetInstance(Type serviceType);
object GetInstance(Type serviceType, string key);
IEnumerable GetAllInstances(Type serviceType);
TService GetInstance();
TService GetInstance(string key);
IEnumerable GetAllInstances();
}
One of the fears I had in participating in this project was that it would promote the approach of Service Location/Dependency Pull over Dependency Injection. I’m glad to see blogs entries like Ayende’s and (more forcefully) Daniel Cuzzulino’s that put this library in the proper perspective.
The intention of this library is primarily for low-level integration between application frameworks. It has a role in business code only as a last resort when you need to ask a container to provide you with a new object instance at runtime that takes advantage of additional container services such as configuration via dependency injection or applying AOP advice. WebForms, WCF Services, and ‘traditional’ server-side objects created at application startup (DAOs, etc) can all be configured non-invasively using dependency injection.
If you find yourself frequently using the service locator approach in your application you should consider refactoring the code to use dependency injection. Not only will you remove an extraneous dependency, always a good thing, but you will get the additional benefit of making your class easier to unit test in isolation of the container as its dependencies will be exposed via standard properties and constructors.
One alternative approach, used in Spring Java but not yet implemented in Spring.NET is to provide a ServiceLocatorFactoryObject, described by my colleague Alef Arendsen here. This allows you to write your own simple service locator interface, for example.
public interface ProcessCreator {
Process CreateProcess(string processId);
}
The container would provide the implementation dynamically at runtime. You can then use dependency injection to configure your class with a reference to ProcessCreator. The only service locator ‘API’ provided with ServiceLocatorFactoryObject are of methods with the signatures IMyService GetService() or IMyService GetService(string id) but others could be envisioned.
comments powered by Disqus
translate：
翻译：
我参与该项目的担心之一是，它将促进服务定位/依赖关系依赖依赖注入的方法。我很高兴看到Ayende和（更强有力）Daniel Cuzzulino的博客条目使该图书馆具有正确的视角。
该库的目的主要是为了在应用程序框架之间进行低级集成。当您需要让容器在运行时为您提供新的对象实例时，它才在商业代码中发挥作用，这需要利用其他容器服务，例如通过依赖项注入或应用AOP建议进行配置。可以使用依赖项注入以非侵入方式配置WebForms，WCF服务和在应用程序启动时创建的“传统”服务器端对象（DAO等）。
如果您经常在应用程序中使用服务定位器方法，则应考虑重构代码以使用依赖项注入。您不仅会删除无关的依赖项，而且总是一件好事，而且还可以获得其他好处，使您的类更易于在容器隔离的情况下进行单元测试，因为其依赖项将通过标准属性和构造函数公开。