Jeremy Miller had some interesting comments on MonoRail as a part of a recent post.
Seems like lots of people are getting pretty hot on MonoRail of late so I thought I would add some extra coin to this one. Last year I built out a reasonable sized internal system using MonoRail and found the experience and results very positive. I was particularly pleased that it made the development experience easier and fun. It was also nice that it worked really well on a larger scale system where I already had a comparative as to how I would do the build using different techniques. It’s a great framework and encourages very logical development and good separation of concerns.
At the time I did the build "as fast as the turtle could go" (ala iterate very early and often ;)) and didn’t put any effort into unit testing some of the units I was writing etc. That’s ok, you live and learn ;)
One of the big benefits IMHO it has over standard ASP.NET Web Forms is that you get a very clean implementation of process logic in your controller methods, it’s very convention driven (ala Rails) and it allows good encapsulation of logic. I think this is a win.
In a nutshell what you get is a new HTTPHandler which replaces the existing ASP.NET pipeline and allows a new class acting as a front controller to receive the requests and start the page process. The controller then decides which View to use and will wire up Model data down to the View to allow it to be rendered. Your view/ASPX page then becomes only involved in rendering (ideally).
e.g.
/Foo/Bar.rails becomes..
FooController.cs
public void Bar(){ // inject your interface process here}
--> Render out through the Bar view (e.g. Bar.aspx if you are using the ASPX view engine)
MonoRail allows a number of different View engines (rendering approaches) to be used. For example you could use an XML/XSLT approach, or use Boo (Brail) to have some power in rendering out intelligently, or you can fall back on ASP.NET.
Now MonoRail doesn’t really play so well with ASP.NET largely because the ASP.NET pipeline needs to be enacted after the front controller to load in the page and cause it to render. This largely causes problems with sequencing around things like button clicks (e.g. My button click event is handled by the Page through the ASP.NET framework rather than in the controller, so it needs to fire things back to the controller to get the process work done.. can just get a bit confusing).
When I was doing my build I took a look at Brail and NVelocity as view engines and to be honest I found them an amazing step backwards from ASP.NET. Maybe I’m just lazy, but I do find that you get a lot of benefit (largely from the automatic eventing and management of control state) inside the ASP.NET framework and it feels like going back to classic ASP in some cases (ignoring some of the control/binding support you get).
Perhaps I am just missing the boat? (or I ultimately suck at HTML/CSS?) :)
Recently we did the build on Background Motion by using the Composite Web block which implements a MVP pattern. Now I totally agree that the MVC in MonoRail gives it a really good story on the testing front but so does Composite Web (WCSF) and at the moment I’m loving the results of what we have achieved with that. You have to abstract away from HttpContext but there are already implementations you can leverage here. IMHO one of the best things about ASP.NET is that you can be quite productive by leveraging the infrastructure and coupling with things like ASP.NET AJAX. It becomes hard to do this "as nicely" with MonoRail .. you can achieve the same results, but my experience was that ASP.NET still has the edge in more complicated form scenarios and ASP.NET AJAX is very nice.
So my main question on all of this MonoRail loving is "Why is MonoRail a watershed?" - I think the simplicity is a very good thing, but come on, don’t let us sacrifice the advancements we have made in productivity and simplicity with WebForms. We are of course still just dealing with HTTP GET's and POST's here :)
I’m still keenly watching MonoRail (and whatever comes out of the ASP.NET team in this space) going forward. I think all of these things ultimately are an evolution in the .NET web application space and its "good times" for us as developers who want some framework support for building more modular and flexible systems. I would love to see some better integration between ASP.NET and MonoRail but ultimately I think part of that needs to come from the ASP.NET team (ScottGu - how about it?)
btw.. If you are keen in taking a look at MonoRail its part of a larger community effort called the Castle Project and it’s definitely worth some time having a nose over.