Castle MonoRail – Response To Comments/Ramblings
Billy has decided to move forward with using MonoRail on one of his current projects. As I was writing the comment on his post to respond to some other folks’ comments, I decided it was getting too long and perhaps I should must make it a post on its own.
Billy stated that his main concern for moving to MonoRail is losing support for 3rd party control suites like telerik. To which a commenter said:
“You don’t have to abandon third-party controls like telerik – just use the WebFormsViewEngine.”
One of the issues with using the WebFormsViewEngine, AFAIK, is that you lose the true MVC-ness of what MonoRail is trying to accomplish for you. The whole idea behind MVC, is that the Controller is the first point of contact for a request, not the View. But when using web forms, you really can’t do that in a nice way (as Ayende points out), since the web form (i.e. ASPX) has to be the first point of contact. Then the View has to implement a special IControllerAware interface and delegate requests back to the controller. And then… we’re back to MVP again.
Of course, MVP is a good pattern in its own right. I’ve successfully used it for years of, dare I say, “classic” web forms development in ASP.NET. But I find the separation and flexibility of a true MVC framework like MonoRail, solves the problem in a much simpler way. Sure you don’t have the bloat, ah hem, *features* like page lifecycles and viewstate. But I still think not having to worry about that kind of stuff is a good thing.
I’ve now used Castle MonoRail in 2 projects and the bottom line for me is that frameworks like MonoRail (and RoR, even though I’ve yet to have had the pleasure of using it) are making web development fun *and* productive again. I haven’t really missed the “server controls” aspect of web forms much at all.
In fact, MonoRail better allows me to develop my presentation/UI layer in the same fashion as I already develop everything else underneath. By using an incremental approach, I can build what I need in a simple fashion and harvest reusable components as necessary.
I’ve experienced the pain of having to utilize 3rd party ASP.NET controls and it’s definitely not all chocolates and roses. Often, in the time you can spend hunting down some nasty bug/behavior in a 3rd party control (that probably does more than you need in the first place) you could’ve leveraged something simpler, even your own solution if needed.
Now I’m most definitely not advocating NIH, but if you can be more productive and deliver more early business value by creating your own solution or extending an existing framework/component, then I would just consider that to be good judgement.
Anyway, I could probably go on and on, but guess that’s enough for now.