Blog post on the defense of Webforms

Ayende has responded to a post by Matts Helander regarding ‘in defense of webforms’.

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 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.).

Monorail doesn’t attempt to hide how the web works. It makes integrating in components quite simply. ie. I used the Yahoo Development tab control make in javascript. Rather than fighting the page lifecycle, registering my javascript with the page, etc… I simply included the tab view in the html of my Monorail page and it works. Nothing is hidden.

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.

I advise reading this article on MSDN about front controllers:

“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



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s