Common Service Locator library clarifications

October 2nd, 2008

The goal of the CSL is not to be used in your app directly. I think we – the need came from the community and was backup by Glenn, Chris and BradA – all understand IoC quite well to come up with something that misses the point :-)

However, sometimes you’re working on an IoC unfriendly ground. WebForms, for instance. You need to access an IoC container directly from a page or web control, you cannot get it “injected” somehow. Another example is pure NHibernate. Ayende’s gave me this example a few weeks ago: he needs to access the IoC container from a custom user type. Those are the scenarios that you might leverage the CSL. Period.

Categories: MS, OSS | Top Of Page | 8 Comments » |

8 Responses to “Common Service Locator library clarifications”

Andy Sherwood Says:

So when you say “not to be used in your app directly”, do you mean I would never write code like this:

var repo = ServiceLocator.Current.GetInstance>();

Seems like the natural thing to do…

Andy Sherwood Says:

Hmm.. My generics were eaten as tags. Subbing squares for angles..

var repo = ServiceLocator.Current.GetInstance[IRepository[DomainObject]]();

hammett Says:

@Andy, in the ideal world using IoC, the container will never be visible to your app. And same thing should be said about the ServiceLocator.

Louis DeJardin Says:

Another example could be in Spark which has an extensibility point for instantiating the compiled view types. One of the things might want to do is have dependency injection of services used by the view, like a menu/nav info provider.

Possibly a controversial use case, since you could say that’s what a helper or filter is for, but it’s an example.

The thing I would worry about referencing the service locator directly from a core library is the same problem I’ve seen with log4net. We don’t use it for application logging ourselves but we deploy it because it’s been referenced, and we’ve had some headaches dealing with deploying assemblies which referenced different versions.

In the end I might still lean towards allowing the application to provide an implementation of the view activator interface to the engine. That could be done with dependency injection, and that implementation could then use the specific IoC to perform it’s task pretty simply.

Along those same lines I’d actually probably prefer if nhibernate contained it’s own flavor of logging interface, and I could give it an implementation which calls log4net or whatever I was using.

hammett Says:

@Louis, I agree. A common set of API for many things – including logging – was proposed about 2 years ago. Getting it adopted is another problem…

Bruno Says:

@hammett

“… in the ideal world using IoC, the container will never be visible to your app. And same thing should be said about the ServiceLocator…”

Thinking about this design point, I believe this “ideal world app” will instantiate a lot of unused objects all the time for stateless operations. I mean:

class
OrquestratorOfSomething

{
public OrquestratorOfSomething(dependencyA, dependencyB)…

public void DoSomething()… uses only dependencyA
public void DoAnotherThing()… uses only dependencyB
}

* OrquestratorOfSomething always receive dependencyA and dependencyB instances, provided by the IoC container, but the caller may be will call just one of these operations, so we end up instantiating an unused object. Is this “overhread” acceptable in a ideal world?

May be I´m not doing enough separation of concerns…

PS: Sorry the poor english.

hammett Says:

I don’t see the overhead. Creating objects is cheap in .Net (as opposed to java).

Aydo Says:

@hammett

I agree with your point of view and imho doing something like this

“var repo = ServiceLocator.Current.GetInstance[IRepository[DomainObject]]();”

smells like not well defined architecture.

Leave a Reply