Over the summer I finally dug into this whole "MVC" thing for web development. Naturally I began with the Mecca of them all Ruby on Rails.  This was a twofold learning experience for me..  First off it was Ruby a meta-language that bends like read in the wind.  And second was Rails, the darling framework that seems to have been sent by the demi-gods of software to help all suffering web developers.

But all of this joy was not without its flaws. Ruby is (as I mentioned before) all but un-deployable on a windows platform. After all Ruby is a single threaded/multi-process language (great for Unix where you don't actually have threads). But this limitation makes it an un-workable option on a windows box. Since then I have dug into Monorail, and now am neck deep in ASP.NET MVC. Heck I'm even a committer on the MVCContrib project. And while these projects are great they are still missing some magic. 

In short I still have stars in my eyes when I think of RoR.. This brings up the question, Why? (ya simple question).  I've been thinking about this a bit and I think (for me) the issue boils down to just a few issues.

First off is the RoR mantra "Convention over Configuration".  This mantra is actually quite deep; and while it can be a touch annoying at times (class naming can get silly) it's actually insanely smart. I have probably downloaded 15 different rails projects and had a working knowledge of the app and how to tweak each one in less than an hour. This is because the sites structure is described 1 way and 1 way only. More over I have been able to hand over projects in no time flat. In short, getting up to speed on a rails project is a no brainer.  ASP.NET MVC missed the mark on this in a big way in my book. MS, wisely from an OO perspective, laid everything out in a strong override-able and design. If you don't like routing, just implement a new router, don't like the view engine, just replace it. MVCContrib continued this with implantations of DI containers like Winsor, Structure Map, etc.. To muddy the situation further, MVCContrib implements multiple View Engines allowing developers to choose between ASPX, NHTML, NVolocity etc.. With all of that we diverge from Convention, and in doing so remove elegance for the privilege of flexibility (* Flexibility I am sure I will be thankful for when I migrate some of my Monorail apps to ASP.NET MVC over the summer).  Monorail is also bad about this (although not as much) with multiple view engines and a solid OO framework; but monorail has a community that has become kind of set in their ways. And so, while not set in stone, some conventions have settled in.  But going back to the rails mantra "Convention over Configuration"; nether ASP.NET MVC or Monorail prescribe to this philosophy more over they are the opposite "Here's a convention, but here are 108 tools to ignore it with " (I jest). 

    The second great feature of rails is the data model versioning and deployment methodology. You want a new data model, you add a new class to your data model describing the changes. Deploy the new version to your dev db, then code. Once your are done you run your deployment in test, evaluate your unit tests and push to prod; all very elegantly and with little effort. Linq for SQL has a great model but you design the app to the data (pulling your object structure from your tables) not the other way around.. So the same model change in Linq starts at the DB (with change scripts so you can manually run them in test and prod later) then re build your mode, code, test, run scripts in test, run unit tests, and deploy using your ant script that took 2 days to write. That's a lot of work and unfortunately Castle active record isn't much better.

    No don't get me wrong I really enjoy using Monorail and ASP.NET MVC has real promise. But when you take these three MVC frameworks and you look at developer efficiency and experience RoR is closest to my heart!