Coming Up For Air
Whew! The past 3 weeks have been intense. I’ve been in a dead sprint to complete the first release version of a new product at work. I’ve also broken from form and written an application for a web platform. It’s a ground-up customization of Reporting Services using ExtJS 1.1 to drive the interface. Very cool stuff, although I’ve cultivated a very strong love/hate relationship with JavaScript over some intense coding sessions.
Finally, I’ve got a chance to catch my breath a little bit before diving back into the other project that I’m working on. That project is more of a marathon than a sprint, though. It’s turning out to be one of the most interesting projects I’ve worked on to date, and I’ve been able to use a bunch of cool technologies on it. Not only has it made development more interesting (who doesn’t love a new toy to play with?) — it’s also made the team vastly more productive.
The project has a whole bunch of moving pieces. Currently, we’re using, in various sections:
- .NET Compact Framework (handheld computers are fun!)
- RFID
- Data replication
- Web Services
- Windows Services
- Remoting
- ActiveRecord
- MonoRail
- Ninject
- log4net
- iTextSharp
- Quartz.NET
As you can probably tell by the insane amount of libraries, we’ve done a good job resisting the not-invented-here syndrome so far. :) Back to the grind!
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.
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.
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).
@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……??
@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.
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.