Yeah i kinda agree with that… something really bad would have to happen before i’d want to switch containers in one of our projects. The whole thing about switching containers during the lifetime of a project is very similar to how people talk about being able to switch ORM’s during the lifetime of a project. A lot of people say they want to be able to do that, while in reality hardly anyone actually does it.

i’m gonna reply to that post later on

@Will

you don’t really need to put a layer on top of it… that’s only useful when you’re writing a framework/library which needs to be able to support multiple containers but for most applications, it’s unnecessary. Again, if you want to switch containers it should only be a very minor change in very few places. Unless of course, you’re using very specific features of a certain container that aren’t supported by other containers. But in that case, a layer on top of it wouldn’t give you any benefit either.

http://www.colourcoding.net/Blog/archive/2010/01/19/dependency-reversi.aspx

in the case of WebForms, we did something like this:

have each page inherit from your YourProjectPage. YourProjectPage has a generic type parameter of TPresenter (or TController of whatever you want to call it). The constructor of YourProjectPage resolves the TPresenter (or TController) in its constructor and all of its dependencies will be supplied by the IOC container. And that’s it… one Resolve statement in your entire Web Application.

In the case of a service layer, either use Castle’s WCF facility to automatically resolve your service instance, or use something like Agatha which does it for you. When the request is received in your service layer, there is essentially one resolve being executed by the container which gives you the component to handle the request. And obviously, all of its dependencies (and their dependencies, etc…) will be fulfilled.

People seem to think that using an IoC is going to reduce explicit code complexity, it doesn’t (well may be StructureMap does with it’s fluent candy). It’s better to centralise your thinking around object life in a central location than have it splintered and spread around multiple factory classes.

My current project is exactly as you describe a central registry and we specifi bootstrappers for WCF, NH and HTTP handlers.

Awkward Coder

You write in your post

” … you’d only have to change your registration code and the one or two places where you resolve something manually through the container.”

Now, as I said I am still new to IoC containers, so this may be a stupid question, but could you give some examples of how to achieve this goal of one or two manual resolves to the container? In the Website I am writing at the moment I seem to have quite a few manual resolves compared to your statement… I am using ASP.NET (but not MVC unfortunately)..

Regards,
Morten

dismissing a practice almost in its entirety based on one bad IOC container or some people’s bad usage of it is completely unprofessional, irresponsible and i’d even say ignorant

He should realize that many people will take his advice and run with it. When that advice is based on faulty data (the ‘bad’ IOC container, or the ‘bad’ usage of some people), there’s quite a bit of damage being done which essentially doesn’t help _anyone_

well – I was really one of the first people to comment on his post (http://twitter.com/kkozmic/statuses/7873032098)
I don’t want to sound like one of these people who follow Uncle Bob blindly, as you described it, but I would give him benefit of a doubt.
The way I see it (I don’t know guice beyond what he shows in the post) – he’s just working with pretty basic container, which does not offer things that .NET container do (what I alluded to in my 140chars tweet). There’s no batch registration, no conventions based injection. It’s .NET 2003 IoC. We were doing the same thing in 2003, and if anything, I treat this post as a testament of how .NET IoC tools are ahead of Java.