Using the library for container independence

Explicit container passing

There are two ways you can use to get an IServiceLocator instance to the place in your code that you need it. The easiest is simply to pass instances around. Your caller will create a container instance, and pass it to you. From there you pass it down to the rest of your application as needed.

Ambient container

Some authors dislike having extra parameters to pass "environmental" details, like a container. For those who choose, the ServiceLocation assembly includes the ServiceLocator static class. This class provides a common access point to get a global container, the Current property.

Libraries should not configure the container

As a library or framework author, understand that you should not be putting anything into the container - that's the job of your caller. Allow the application writers to choose whatever container they want. You need to document what services you need registered, and if you're using the ServiceLocation.Current ambient container.

Should I use this library for my applications?

Typically, the answer to this question is no. Once you've decided on a container that suits your project, there's not a whole lot of benefit from writing your whole application in a way that can switch containers. For libraries that must fit into other ecosystems and play nicely with other libraries, it's an important feature, but for applications the extra layer of abstraction really doesn't buy you much.

Last edited Sep 30, 2008 at 8:10 AM by ctavares, version 1

Comments

nzdunic Oct 21, 2009 at 4:32 AM 
As a protection wrapper it is fine to use this. It's good protection. Your own additions can help in testing scenarios to use different configs.