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 t