Techno-Babble

ASP.NET WebForms: As *Component Frameworks* Go, It’s Pretty Good

I just want to talk for a moment about the things that are good about WebForms.

WebForms is a Component Framework

First of all, we have to acknowledge that WebForms is a component framework.  Many people who are critical about ASP.NET WebForms are actually criticizing the whole component approach to web development.  Others criticize component frameworks because of their experience with web forms.  If we’re going to have a decent discussion about this, we need to separate the two.  WebForms is one take on a component UI framework for web applications.

What is a component framework?  The simplest answer is that it allows for modular user interface elements (components) to be clumped together to form bigger components, and so on.

It also means that those components generally manage their own:

• State
• Behavior
• Display

However, there is usually also a lot of sophistication that allows developers to inject their own implentations of those elements wherever necessary. A major component framework flaw is when the framework doesn’t allow this very well.  For example, this was something that WinForms didn’t do very well.  If you wanted to change the way something was displayed, you just had to override how it was rendered.  WPF, on the other hand, is amazing at this sort of flexibility.  Their whole approach with lookless controls and ultra-powerful data-binding is just awesome, and I don’t think it’s been fully grasped or appreciated yet.

Component-oriented applications are more powerful and intuitive, at the cost of being more complex.  I see this as good rather than bad.

ViewState: A Good Solution to a Hard Problem (but Poorly Implemented)

ViewState is useful and sometimes the best or only solution to a legitimate problem.

It’s a solution to state problems in web apps.  Statelessness is essential to the web, but it’s the achilles heel of web apps.  So we have state options like the form, cookies, and the querystring.  And sessions, identified by state from the other list.  That’s about all you get.  Sessions are useful because they are giant buckets, but they jack with clusterability and scalability and they span multiple browser sessions.  The only state options that are specific to the actual user action are the items in the HTTP request - the form and the querystring.  So MS saw the utility of having a “state bucket” for Session and applied the same concept to the Request.  It’s really convenient and very useful when you need it.

By itself, it’s not that hard to do, and one could (and should, IMO) be able to quickly implement such a mechanism in an MVC app, for use when it is called for.

Unfortunately, the only truly idiot-proof (which seems to have been the guiding value in the design of webforms) way to pass viewstate is in a POST, which sucked us down into the horrible “Everything’s a PostBack” circle of hell.  Plus the framework really pushes you in the direction of ViewState bloat, to the point that you don’t even know it’s happening half the time.  That’s all bad.  Horrible.  But it’s primarily just a bad implementation detail plus bad education.  It’s not irreparable, and the complexity actually isn’t in ViewState.  That brings us to the truly complex bit, which is also the most sophisticated bit, and the thing that, when coupled with ViewState, can be totally awesome or incredibly dangerous…

The Control Tree and the Page Lifecycle

This is what makes WebForms what it is.  It is a component framework.

It was way ahead of its time and never appreciated.  Java started to move past MVC and then got hung up on it again when Rails became popular.  But the next thing for Java was Java Server Faces, a component framework, consisting of a component tree with a complex lifecycle.  JSF was great in theory but all the initial implementations were pretty flawed because this is hard stuff to get right.  After having worked with JSF and then Facelets (which was a fantastic, one-man improvement to the problem), I must say kudos to MS for building a remarkably stable component framework.  The framework is great.  Unfortunately the controls themselves are flawed and confusing and the whole system is incredibly complex and closed source and poorly documented.

But, component frameworks are incredibly useful and the pattern should not be thrown out just because MS messed up some details.  It’s not irreparable, and I hope that my discussion of MVC helped establish that while we act like it’s the pattern that is what matters, it’s all the other stuff that really drives our adoption of a particular platform / approach.

Code-Behind: Seriously, how can you hate code-behind?

Separating markup from code while allowing them to live in the same class / instance — this is great.  Why would you ever not want to have this capability?

It comes down to restraint, which I noted as being one of the great virtues of the MVC mindset.

However, an interesting aspect of the MS adoption of MVC is hearing the exclamations of uppity architects who don’t trust their developers with code-behind.  But they don’t trust their developers with anything.  These are the folks who want to use Guidance Automation not as a helper, but as reigns and blinders on delinquent, mediocre developers.  I have no sympathy for that mindset.

The other argument againt code-behind is that it impedes testability.  Now here it’s important to determine what testability really means and how important it is to you.  Aside from “library” and “framework” projects, I seldom see a TDD initiative that is effectively testing anything but their data access layer.

The reality is that clean separation of layers is a good value, but so is tight coupling, sometimes, and so is development speed, and so is testing, and you need to balance all these things, but code-behind is fundamentally a good and useful mechanism and you just need to decide how you want to use it.  I really like how we use it.  Someday I’ll elaborate with some code snippets.

Tags: ASP.NET, Components, Frameworks, WebForms