I must agree with Ayende, and after many many projects & years of developing webform applications, what he writes is true. Webform’s appeal is in it’s separation of the UI from the code with a page controller architecture. It’s very similiar to what you expect in a Winform’s application. However, the page lifecycle and the attempt to give the illusion of state becomes a burden on a more complex page. Some areas of webform development is nice – mostly databinding and some of the new ajax capabilities. But even then you will find your fight the page lifecycle rather than just develop a solution.
So, in comes Monorail. Monorail removes this page lifecycle from asp.net and provides a viewengine instead. NVelocity or Brail, etc…
The one thing I would personally like to do is to eventually learn boo and brail. Ayende has written some Monorail smart components that show how easily it is to implement your own controls. I would love to see the Monorail community create a repository of view components with common functionality (ie. validation components, grids, ajax components, etc.).
I could go on and on, but I feel the response by Ayende is right on.
The only struggle I see right now is convincing your organization to adopt Monorail, but I would think the developers would quickly adopt it because it makes their life easier, and developers don’t have to constantly fight the page lifecycle of Webforms.
For me the added benefit of Monorail also includes the ability to plug in a DI/IOC container and utilize ORM capabilities. All are pluggable and can exist independently.
This was my response to his post:
On the MVC the biggest problem I have with WebForms is that the page logic is called prior to the â€˜controllerâ€™ logic.
The webform model is referred to as a â€˜page controllerâ€™ architecture.
A MVC like Monorails uses a â€˜front controllerâ€™ architecture. ie. http://www.martinfowler.com/eaaCatalog/frontController.html
I advise reading this article on MSDN about front controllers: http://msdn2.microsoft.com/en-us/library/ms978723.aspx
â€œYou have reviewed the Page Controller pattern, but your page controller classes have complicated logic, are part of a deep inheritance hierarchy, or your application determines the navigation between pages dynamically based on configurable rules.â€
Sounds familiar of webforms â€¦
So, what does something like Monorail achieve?
â€œFront Controller solves the decentralization problem present in Page Controller by channeling all requests through a single controller.â€
I think the idea of â€˜postbacksâ€™ is what really complicates the webform model. You are managing different states by determing if you are in â€˜postbackâ€™ or not. That is the start of the complexity for me. Your left trying to manage the â€™stateâ€™ of that page through the statebag, session, etcâ€¦ to attempt to recreate that page.
I have used a MVP (presenter) setup, and although it does what you suggest, separating the presenter logic from the view logic, I still find working with a system like Monorail is much more straight forward.
But again,I see the differences as â€˜front controllerâ€™ vs. â€˜page controllerâ€™. Obviously both have tradeoffs