Techno-Babble

On the WebForms vs MVC Debate

Actually, it’s not a debate — it’s incredibly one-sided, which is the reason that I’m going to write a few blog posts to say:

Webforms doesn’t totally suck.

We recently chose it over ASP.NET MVC for a reason.

Part of the reason is that I and my team have had PLENTY of experience with MVC in Java and in Ruby on Rails.  It’s just a pattern.  It’s good for some stuff, sure.  Actually it’s good for most stuff.  But there’s very little to the underlying approach that makes it incompatible with WebForms.  Well, that depends on your interpretation, I suppose.  The concept of MVC has been re-interpreted so many times that it’s now a giant bundle of behaviors, assumptions, conventions, and religiosity, barely any of it essential to the original concept, such that few discussions of it are not prejudiced in one way or another (kinda like society’s concept of marriage).

MVC is better than V

It’s definitely a step up over scriptlets, i.e. classic ASP/JSP.  Why, though?  Because that approach led to really gigantic pages filled with lots of duplication and spaghetti code.  The list goes on.  I’m not even going to bother with it.  Those were the dark ages.  They were horrible.  But really, folks, anything is better than that.

ASP.NET WebForms was ahead of its time, sort of

What’s funny is that although the motivation appears to have been a really bad one (to allow developers to build webapps like they build VisualBasic apps), WebForms was really ground-breaking at the time.

I’m pretty sure no one appreciated it.  My application development group certainly didn’t appreciate ASP.NET when it came out.  We had consultants showing off all sorts of nifty features, but it was just plain weird.  Data access was a beating, validation was weird, the viewstate stuff was ridiculous, and debugging was a pain.  We always ended up with more code and more bugs.

So we actually switched the whole shop over to Java.  Granted, we could have been on the extreme early adopter side of ASP.NET, but I don’t think I would have wanted to be.  I still think it was the right decision to switch to Java.  It was a great time for Java.  The open source stuff that was going on was ground-breaking and top notch.

MVC is like plain oatmeal: sugar makes all the difference

We used Struts.  Struts was ground-breaking at the time: it was MVC.  As with ASP.NET, it was definitely a different approach than classic ASP/JSP.  But it was an easy transition.  All you had to understand was that controller stuff happens before the page is rendered, and the page should just render a view of the model objects passed to it by the controller.  Simple.  That’s MVC.  Not that ground-breaking.  Separate the M from the V from the C.  And there, the real value for me has always been having an M.  Decoupling the controller from the view is great in theory, but I seldom did so.  Nearly all of our actions returned the “success” view.  Most Rails actions return the same view, same with what I’ve seen in ASP.NET MVC.

So I’d say that MVC in its pure form is not that impressive, and I don’t think it really took off until the open source crowd started sweetening it with lots of sugar.

MVC is great because of all the other stuff that you end up plugging into the MVC lifecycle.  It’s great for interception, pipelines, IOC, O-R modeling, repositories, and automated request binding, sophisticated containers like Spring and Castle that inject AOP and declarative transaction handling, etc.

And let’s face it - Rails was the real force behind MVC.  Java had a hundred MVC frameworks before Rails was around.  So, while Rails is MVC, that is not its differentiator.  ActiveRecord is a big part of it.  O-R mapping is awesome and I’ll spend some time on that in another post.  Rails also had lots of convenience, automatic model generation based on the DB schema, Routes, Ruby itself (which is awesome), built-in AJAX support from the beginning, is free and open source, had an outspoken team promoting it, and a huge community supporting it.  That’s why MVC is so popular.

So really, the thing that was great about MVC was convenience and convention.  MVC reinforces the use of conventions, and no one really started using MVC until a bunch of convenience mechanisms were there.

Struts pales in comparison, but it was huge for a while, and the reason was also NOT because it was MVC (aside from the fact that Java devs loved to go around talking about MVC because name-dropping patterns was all the rage).  The rocking aspect of Struts was its configuration options, its convenient databinding, and the struts taglibs.

Of course people are going to say that the reason they were able to build all that stuff in is that MVC has a lot of merit.  I think it has merit in the same sense that Dark Room has merit for getting writing done.  It’s so austere in its initial simplicity that it forces you to focus, rather than get distracted by the bouncing paperclip, your email, GridViews in the Designer, etc.

It sets a tone of restraint from the beginning, which makes it easy to build a lot of clearly layered stuff on top of that such that you have an architecture that is clean and upholds your personal/team/organizational values.

No argument here, but the values themselves are a lot more important.

It’s all about principles

MVC is a means to an end, obviously.  But it’s also the means by which people are most often able to develop according to their principles.  And the principals are really much more interesting than MVC itself, which is about as interesting as oatmeal.

If you haven’t inferred it from the lack of code snippets, hyperlinks, and other concrete support, this is an editorial post.  Which means that no one will probably make it all the way through it, and will just skip down to the comments section and post their editorial remarks (that is, if anyone ever reads this at all).

Anyway, I’m no longer steeped in MVC lore, so feel free to suggest refinements to this, but I think that what’s underneath MVC is principles like

• Convention / Consistency - in terms of file organization and naming conventions.  Convention is really powerful and I should probably dedicate a whole post to it
• Simplicity - terse, readable code
• Separation of Concerns - in order to maximize reuse and longevity
• Dependency Injection (formerly known as Inversion of Control)
• (Automated) Testability - which really depends on separation of concerns and dependency injection.

Let me just say that I wholeheartedly believe in all of these principles (oh wait — except for the last one.  ooooh I’m sooo controversial.  More on testing later).

Anything you can do…

If I had the time, I’d do a little grid explaining how MVC facilitates the maintenance of these principles and how various MVC implementations support these ideals.

But I don’t have the time, so let me just say that there’s nothing here that can’t also be done, fairly easily, within WebForms.

It’s just that no one is doing it.

WebForms itself sucks much less than the Microsoft and Developer Community Approach to It

There is no broad community trying to perfect a set of patterns and tools for WebForms.  The WebForms community is broken.  We largely swallowed the pill given us by MS, and there has been very little innovation, most of it falling on rocky ground and failing to thrive.

And everyone knows that the well-known approach propagated by MS for building WebForms is fundamentally flawed in that it upholds none of the values listed above, and that’s why everyone loves MVC so much is because of its contrast to WebForms.

So, we kind of threw out the baby with the bath water, I think.

If we pare back the religiosity for a moment, I think that we could perhaps establish that there are certain scenario / team / timeline / customer / implementation details that could lead to either an MVC or a component-oriented architecture as the best solution.  More to come.

Tags: ASP.NET, MVC, WebForms