关于ServiceLocator模式
http://www.cnblogs.com/hwade/archive/2011/01/30/CommonServiceLocator.html
为什么是Anti-Pattern
起源于同事发给我的链接 http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
结合总结工作中使用ServiceLoactor模式遇到的问题。
- 依赖关系不明确,ServiceLoactor在各个方法中使用,无法直观了解对象之间的引用
- 如果对象未正确注册,只有执行到ServiceLoactor.Resolve时才会抛出Exception。使用构造器注入可以更早发现问题。
- 维护对象以及生命周期的控制。
var instance1 = ServiceLocator.Current.GetInstance();
var instance2 = ServiceLocator.Current.GetInstance();
以上客户端程序中出现这样的代码。是否 instance1 == instance2 ?
光看这段方法这是无法确定的。 导致误解造成程序预期之外的的运行结果。甚至在其他对象中调用了ServiceLocator.Current.GetInstance()并且修改了内部状态导致异常结果。
在MVC中也实现了ServiceLocator模式
//容器集成MVC
var locator = new NinjectServiceLocator(kernel);
DependencyResolver.SetResolver(locator);
//使用
var customerService = System.Web.Mvc.DependencyResolver.Current.GetService(typeof (ICustomerService));
这个对象无法在非MVC中复用运行,在单元测试时,也必须提前初始化DependencyResolver.Current
总结
标题党了“Anti-Pattern”,不是说它不好不能用。其实只是需要注意使用的方法。一个好东西不注意使用方式或者滥用就失去了它的意义。