Comments on: Coming Up For Air

By: Nicholas Blumhardt

Nicholas Blumhardt — Sun, 18 Nov 2007 09:01:56 +0000

Nate, guess that is a fair stumbling block As you’ve pointed out, most of the decision to use one container over another revolves around the API.

Modules might play a big part in some people’s decisions – e.g. if I’m using NHibernate then a pre-built NHibernate module will make a particular container more attractive.

99% of registrations in any container will be (name, type, service, lifecycle) – perhaps a common adapter onto a minimal subset of each container API would be enough that we could write many modules in a container-agnostic fashion?

I can see a stumbling-block or two (or three) here of course, but it would be really neat to be able to use a single module implementation on Ninject, Windsor, or whatever. I’m probably dreaming big-time

Sounds like a really interesting project you’re working on, BTW.

By: Nate Kohari

Nate Kohari — Mon, 12 Nov 2007 12:09:30 +0000

@Nicholas: The code that supports injection and lifecycle is pretty much the same throughout all of the DI frameworks — because there’s not a whole lot of different ways to write it. The main difference between the frameworks is the API.

Ninject’s API is vastly different than the other containers… not because it uses a fluent interface, but because it’s geared around the idea of evaluating conditions based on context rather than just key associations. This, of course, has benefits and detriments, and isn’t perfect for all situations. It’s more expensive to evaluate conditions than it is to look up component keys like Windsor or Spring does. However, it lets you come up with some pretty exotic binding situations.

I think that a standard container will only happen if Microsoft creates one themselves. That’s not to say that they will create the One Container To Rule Them All, but (as I think we’ll see with the upcoming ASP.NET MVC framework) when Microsoft throws its weight behind an idea, it becomes mainstreamed much faster than if it’s just the OSS community.

By: Nicholas Blumhardt

Nicholas Blumhardt — Mon, 12 Nov 2007 10:36:36 +0000

@ShaunC, if you dig into Ninject you’ll find it is quite different to Windsor. Windsor is great but the open source culture thrives on diversity.

container.Bind().To();

.. is easier on my eyes (and wrists.) By the gradual accumulation improvements we move on. In five years, will we all be using Windsor? I never thought it would happen, but no sooner has Subversion reached mass acceptance than we’re moving on to Git/Darcs/Mercurial/Bzr….

Nate, do you think it is possible a ‘standard’ container configuration API will emerge the way JPA did? Perhaps something like that would turn into a lowest-common-denominator approach. It couldn’t hurt to have a standard API for the commonest scenarios like the one above though……??

By: ShaunC

ShaunC — Wed, 03 Oct 2007 16:34:16 +0000

But, you don’t have to use an XML config file.

container.AddComponent(typeof(TImplementation).FullName, typeof(TService), typeof(TImplementation))

also the footprint required is very small (as far as managed apps go anyhow).

By: Nate Kohari

Nate Kohari — Thu, 27 Sep 2007 15:22:40 +0000

The Castle Project is great, and Windsor is one of the best IoC solutions out there, particularly for large, enterprise projects. I use MonoRail and ActiveRecord in my own work.
However, I believe Windsor’s reliance on XML for configuration is a major weakness. Through its fluent interface, Ninject lets you take advantage of your language (type-safety) and your IDE (code completion).
Windsor is also pretty sizable. If you’re writing a large application, that’s not a problem, but I believe inversion of control can be applied to projects of all sizes. Ninject was created specifically to be small, fast, and simple. (In fact, I have a version that I use on the compact framework.)
Windsor does have a lot of nice integration points, but they’re largely due to the maturity of the project. Ninject is very young, but is built to be extensible as well. I’m writing integrations as I need them. (In fact, there’s an extension to integrate with Castle MonoRail.
In the end, Ninject and Windsor just attack the same problem from different angles. Comparisons between the two are often apples-to-oranges… they both have strengths and weaknesses. It’s also largely a matter of taste. I would never say “don’t use Windsor” — but I would say give Ninject a shot.

By: ShaunC

ShaunC — Thu, 27 Sep 2007 14:52:31 +0000

Not sure why you invented ninject – Castle Windsor/Microkernel does the job and the amount of facilities it has are really good – supporting threading issues with UI for one. We have recently adopted it and we are amazed about what we get for free plus it’s well supported – less to fix in your own app.