Experiencing ASP.NET MVC deja vu

Throughout the past year or so, I've been hearing and reading a lot about the ASP.NET MVC system. According to some folks, it is this revolutionary new thing that is going to turn the world of web development upside down. To be honest, I didn't quite see it that way.

Part of the problem is that it took months of learning to get a handle on what people were so excited about with ASP.NET MVC. Every time I asked point-blank, "What's the benefit?" I would get blank stares and non-answers, or at best, the usual vague list of "less debugging, easier maintenance, more agile, etc" that folks use to push just about every new development in programming. To make matters more complicated, nearly everyone I saw trying to explain MVC used a variant of the same meaningless diagram with three circles with arrows pointing to each other. The more folks talked about MVC, the less interesting it looked to me. But a few months ago, I found out why it seemed so uninteresting: because it is only new to ASP.NET developers, and if you have ever written a PHP script or a typical CGI style script, it is nothing new at all.

When I say that to ASP.NET MVC fans, they ask, "How dare you say that it isn't new and innovative and revolutionary?!" Well, it isn't. For one thing, the MVC pattern has been around forever. And of course, ASP.NET MVC is hardly the only MVC implementation for web apps, let alone ASP.NET. But putting all of that aside, if you strip out the niceties that a good MVC framework will provide (like a standardised system for routing requests), the overall workflow is not much different from some fairly old-school applications.

Take the routing, for example. While ASP.NET MVC's routing system is nice, for the majority of the applications out there, it is a glorified switch statement. If you've ever worked in CGI or PHP, you most likely had this kind of workflow:

|> Perform baseline initialisation (load the session, for example)
|> Have a switch statement that examined some aspect of the request, usually a variable in the URL's query string or a POST variable, and then call the appropriate sub-routine based on that value, usually passing along the entire request (maybe after some parsing) or just exposing it as a global item, for ease of maintenance
|> The sub-routine provided a bunch of data to be based back to the main routine, which used that data to generate HTML perhaps with a templating system

This workflow describes ASP.NET MVC to a T, too.

Here's where things get a little weird for me. A few months ago, I was talking to a buddy of mine about how I felt totally clueless about ASP.NET MVC, and I realised why I never saw the liberation that other ASP.NET developers see in ASP.NET MVC: I never properly learned the ASP.NET WebForms way of doing things! I missed the Classic ASP and VB6 years — I was a Perl/CGI guy then.

When I shifted to ASP.NET, I didn't bother to learn the "right" way of doing things — I would just kludge together things that were as close to the CGI model as possible, making just enough adaptations to work in ASP.NET. I had a tendency, for example, to avoid databinding and preferred things like the repeater style objects that let me control exactly what was happening. I avoided post-backs like the plague because they felt foreign to me. And so on.

So I never really hit so many of the complexities of ASP.NET WebForms (like the event model that no one seems to fully understand) because I never used it. To me, ASP.NET MVC is deja vu, but for someone who has been using WebForms, I can definitely see why it feels like freedom. I had always resisted WebForms because I never saw enough benefit to justify the restraints, and now developers who knew nothing but WebForms are delirious now that they have options. It reminds me of the Platonic myth of the cave.

Regardless of your history with web development, I encourage you to check out ASP.NET MVC if you are a current web developer. Also, make sure you look at the Spark View Engine to fully free yourself from WebForms.

Via TechRepublic