问题
I have read often that Service Locators in IOC are an anti-pattern.
Last year we introduced IOC (Ninject specifically) to our application at work. The app is legacy, it's very big and it's fragmented. There are lots of ways a class, or a chain of classes can get created. Some are created by the web framework (which is custom), some are created by nHibernate. Lots are just scattered around in weird places.
How would we handle the different scenarios and not come up with something thats not at least ServiceLocatorish and not end up with different kernels in different places (scopes like singleton, HttpRequest and thread are important).
Edit I'll add a little more detail to what led us to our current SL pattern.
We actually don't want multiple kernels. We just want one (and indeed because of the SL we only have the one static one). Here is our setup:
1) We have Ninject Modules in 7-8 different projects/assemblies. When our app (a webapp) starts the modules are gathered via assembly scanning and loaded into a kernel and placed in the Service Locator. So all that is rather expensive.
2) We have a custom UI framework that's construction happy. Think of around 120 tabbed forms which each construct 1-10 tab pages as part of their lifecycle. The SL is strategically used in 5-6 places which cover all of this either as pure resolution or doing post instantiation injection of properties only.
3) Anything under the UI is not covered by those top level calls and if those classes want to use IOC they need to come up with their own strategy. There are various different little frameworks which are each their own little worlds.
So the ideal way of doing it from what I have read is injecting a kernel whenever you need to access IOC...well that's all fine and good; we do keep the use of the SL to a minimum.
But where am I getting this kernel from? I don't want to construct and register up a new one everywhere. It seems like I would have to get it out of static context or factory so I can ensure that the kernel I'm using is holding on to the same scoped objects that everyone else is using and also to avoid the expense of registering all of the modules. At that point, whatever that thing is seems a lot like a Service Locator right?
Keep in mind also that this app is HUGE and tightly coupled. We don't have the luxury of spending a few months in one go of refactoring it. The SL seemed like a good way for us to slowly work IOC in where we could as we had time.
回答1:
So the ideal way of doing it from what I have read is injecting a kernel whenever you need to access IOC...well that's all fine and good; we do keep the use of the SL to a minimum.
No, injecting the kernel into your business classes is not the best way to go. The better way is to create a factory e.g. IFooFactory { IFoo Create(); } or Func<IFoo> and let this one create the new instance.
The implementation of this interface goes into the composite root, gets an instance of the kernel and does the resolve using the kernel. This keeps your classes free of a specific container and you can reuse them in another project using a different container. In case of Func you can use the following module: Does Ninject support Func (auto generated factory)? Ninject 2.4 will have native support for this.
As far as the refactoring goes, it is hardly possible to tell you what's the best way to go without knowing the source code of your application. I can just give you an approch that probably can work.
I suppose you want to refactor the whole application to proper DI in long term. What I did once for a quite large project (30-40 man-years) was about the following:
Start at the composite root(s) and work down the object tree and change one class after the other to use proper DI. Once you reached all leafs start to refactor all the services that do not depend on other services and work to their leafs using the same approach. Afterwards, continue with the services that depend only on services that have already been refactored and repeat until all services are refactored. All these steps can be done one after the other so that the code continously gets improved while new features can still be added at the same time. In the mean time ServiceLocation is acceptable, as long as the focus is to get it right as soon as possible.
Pseudo code example:
Foo{ ServiceLocator.Get<Service1>(), new Bar() }
Bar{ ServiceLocator.Get<IService1>(), ServiceLocator.Get<IService2>(), new Baz() }
Baz{ ServiceLocator.Get<IService3>() }
Service1 { ServiceLocator.Get<Service3>() }
Service2 { ServiceLocator.Get<Service3>() }
Service3 { new SomeClass()}
Step 1 - Change Root (Foo)
Foo{ ctor(IService1, IBar) }
Bar{ ServiceLocator.Get<IService1>(), ServiceLocator.Get<IService2>(), new Baz() }
Baz{ ServiceLocator.Get<IService3>() }
Service1 { ServiceLocator.Get<IService2>() }
Service2 { ServiceLocator.Get<IService3>() }
Service3 { new SomeClass()}
Bind<IBar>().To<Bar>();
Bind<IService1>().ToMethod(ctx => ServiceLocator.Get<IService1>());
Step 2 - Change dependencies of root
Foo{ ctor(IService1, IBar) }
Bar{ ctor(IService1, IService2, IBaz) }
Baz{ ServiceLocator.Get<IService3>() }
Service1 { ServiceLocator.Get<Service2>() }
Service2 { ServiceLocator.Get<Service3>() }
Service3 { new SomeClass()}
Bind<IBar>().To<Bar>();
Bind<IBaz>().To<Baz>();
Bind<IService1>().ToMethod(ctx => ServiceLocator.Get<IService1>());
Bind<IService2>().ToMethod(ctx => ServiceLocator.Get<IService2>());
Step 3 - Change their dependencies and continue until you are at the leafs
Foo{ ctor(IService1, IBar) }
Bar{ ctor(IService1, IService2, IBaz) }
Baz{ ctor(IService3) }
Service1 { ServiceLocator.Get<Service2>() }
Service2 { ServiceLocator.Get<Service3>() }
Service3 { new SomeClass() }
Bind<IBar>().To<Bar>();
Bind<IBaz>().To<Baz>();
Bind<IService1>().ToMethod(ctx => ServiceLocator.Get<IService1>());
Bind<IService2>().ToMethod(ctx => ServiceLocator.Get<IService2>());
Bind<IService3>().ToMethod(ctx => ServiceLocator.Get<IService3>());
Step 4 - Refactor the services that do not depend on other ones
Foo{ ctor(IService1, IBar) }
Bar{ ctor(IService1, IService2, IBaz) }
Baz{ ctor(IService3) }
Service1 { ServiceLocator.Get<Service2>() }
Service2 { ServiceLocator.Get<Service3>() }
Service3 { ctor(ISomeClass) }
Bind<IBar>().To<Bar>();
Bind<IBaz>().To<Baz>();
Bind<ISomeClass>().To<SomeClass>();
Bind<IService1>().ToMethod(ctx => ServiceLocator.Get<IService1>());
Bind<IService2>().ToMethod(ctx => ServiceLocator.Get<IService2>());
Bind<IService3>().To<Service3>().InSingletonScope();
Step 5 - Next refactor those that depend on services that have only refactored services as dependency.
Foo{ ctor(IService1, IBar) }
Bar{ ctor(IService1, IService2, IBaz) }
Baz{ ctor(IService3) }
Service1 { ServiceLocator.Get<Service2>() }
Service2 { ctor(IService3) }
Service3 { ctor(ISomeClass) }
Bind<IBar>().To<Bar>();
Bind<IBaz>().To<Baz>();
Bind<ISomeClass>().To<SomeClass>();
Bind<IService1>().ToMethod(ctx => ServiceLocator.Get<IService1>());
Bind<IService2>().To<Service2>().InSingletonScope();
Bind<IService3>().To<Service3>().InSingletonScope();
Step 6 - Repeat until every service is refactored.
Foo{ ctor(IService1, IBar) }
Bar{ ctor(IService1, IService2, IBaz) }
Baz{ ctor(IService3) }
Service1 { ctor(IService2) }
Service2 { ctor(IService3) }
Service3 { ctor(ISomeClass) }
Bind<IBar>().To<Bar>();
Bind<IBaz>().To<Baz>();
Bind<ISomeClass>().To<SomeClass>();
Bind<IService1>().To<Service1>().InSingletonScope();
Bind<IService2>().To<Service2>().InSingletonScope();
Bind<IService3>().To<Service3>().InSingletonScope();
Probably you want to switch to a convention based container configuration together with the refactoring. In this case I'd add an attribute to all refactored classes to mark them and remove it again after all the refactoring is done. In the conventions you can use this attribute to filter for all the refactored classes.
来源：https://stackoverflow.com/questions/6562872/avoiding-service-locator-antipattern-with-legacy-app-not-designed-for-ioc