Ted Neward -> Ruby on Rails -> Monorail -> Castle Project -> IOC -> WTF?

I like Ted Neward, he frequently posts interesting stuff and is probably as across the .NET and Java worlds as it is possible to be. He’s been causing a bit of a controversy on his new technical weblog by not immediately falling at the feet of Ruby on Rails, the cool web development framework du-jour (as opposed to the cool web application architecture du-jour AJAX. Warning the fusion of these technologies in Ajax on Rails could result in a web development programming fad singularity after which we’ll all have to go back to writing green-screen mainframe applications). Somewhere in the conversation I heard about Monorail, a “rails for .NET”. This sounded moderately interesting to me since (AFAIK) there haven’t really been any attempts to develop “alternate” web GUI platforms on top of the CLR that compete with ASP.NET. I had a brief look at Monorail (formerly called Castle on Rails - more on that in a minute). The intention seems to be to strictly use the MVC pattern to explicitly seperate out the different elements of the application. Interestingly it can use both ASP.NET and NVelocity for templating, so ASP.NET becomes “just another templating engine“. Monorail is part of a larger project called Castle Project which seems to be building a serise of  tools to “speed up the development of common enterprise applications and server applications while enforcing a good design.” (with the apparent focus being working in the .NET world). Aside from Monorail one of the Castle Project’s other “big ideas” is IoC, and they have two IoC containers (one called MicroKernel and one called Windsor…Windsor Castle…get it). Windsor is layered on top of the MicroKernel. After reading through a bit of their documentation I was struck by how much this seemed to duplicate what is already built into the framework in the System.ComponentModel namespace. I really couldn’t see what the “killer feature” that either Windsor or MicroKernel provided over the stuff that is just built right in. This strikes me as a bit of a WTF. Although I CAN see the benefits of a strict MVC architecture (MonoRail) as well as the drawbacks (like throwing out all of System.Web.UI) I was really at a loss as to what these IoC containers provided. Writing stuff for the community is great, but please please please people, if your widget provides something new and compelling compared ot the one that comes in the box then spell it out in an H1 tag in a prominent place on your site. Maybe I just need to refresh my memory on all the IoC stuff and what System.ComponentModel does and does not provide….


Hi there,

I didnt know that System.ComponentModel family of classes were capable or auto-wiring components - through inversion of control in a non-intrusive fashion (instead of using IServiceProvider.GetService which is intrusive) and externalize configuration and provide an orthogonal extensibility point where one extension does not impact on others. Is it? If so I can delete all my code from SVN and recall the project :-p

This might help

and these:

Both are somewhat out dated, but might help ;-)

21/08/2005 3:09:00 PM
Hmm…..thanks hammett. I wasn’t disputing that your stuff provided something new, just that it wasn’t very well spelt out. In fact I’m still not sure how MicroKernel’s code for aquiring services (from http://www.castleproject.org/index.php/MicroKernel)

ICustomerServices instance = kernel[ typeof(ICustomerServices) ]
as ICustomerServices;

Is all that different from IServiceProvider.GetService (except that your container can take a type or a key). How orthogonal are the features provided by the MicroKernel and what’s in System.CompontnetModel? Perhaps I should have paid more attention to Windsor and less to the MicroKernel. I’m quite fond of configuration-driven factories which seems to be something Windsor uses a great deal.
21/08/2005 5:00:00 PM
OK - I think I’m starting to understand where and why auto-wireup might be quite useful. I’d still be interested in seeing a write-up on how and why this type of IoC container is better/different to System.ComponentModel
21/08/2005 5:29:00 PM