Things that we hated about classic asp but still exist in webforms today

Question

I'm working on a list of reasons for my team to move from webforms to MVC and I thought a good place to start was showing the "why we should migrate" with a set of things both classic asp and webforms have in common.

Such as:

Spagetti Code (violation of SRP)

Classic ASP - each .asp file felt like a big ball of mud
Webforms - this big ball of mud went from the view to the infamous "codebehind"

Keep in mind that my developers are not the type to implement something like MVP w/out being pushed and this is part of the reason I like MVC (although keeping the controllers thin will be a learning experience)

Update I'm aware that you can create a mess in any language on any platform. I'm also aware that MVC won't solve this. I'm also aware that some real mentoring needs to be done to get a team writing a mess to understand why this is hard to maintain. But I feel that this opportunity is one that will allow me to express the need for SOC/Responsibility Driven Design/Testability/etc.

About writing more maintainable software with webforms: From my experience implementing a presentation pattern like MVP in webforms to respect SRP/increase maintainability/enable unit testing/etc is a LOT more work than using MVC out of the box (and you get the same results). Does it work - yes and I have had success with this approach in the past. But if I could instead leverage a much more natural approach to web development that was baked into the platform, I would.

I was looking for someone to point at things that the average 9-5 developer "wanted" to get away from when they wrote classic asp but after they got into webforms never follwed through with. (again - most of the developers I work with simply took the mess they complained about in classic asp and moved it to the code behind and "thought" this was a step in the right direction).

Answer 1

Part of the problem is that you can easily have "Spaghetti Code" and "Big balls of mud" with badly written MVC views - if you say it's going to be a "learning experience" keeping your controllers thin, then you're going to have difficulty keeping your Views clean and tidy as well.

See also StackOverflow.com Search for "WebForms vs MVC" for other similar questions with the sort of arguments you're looking for.

---

Edit in response to question's edit

Ok, things I dislike in ASP.NET that have been removed/resolved by ASP.NET MVC:

1. Having to remember to set ViewStateEnabled = false to decrease my page sizes.
2. Having little control over the client-side id's of controls (this will be resolved in ASP.NET 4.0 however, where you can set the ClientID).
3. Having little control over the rendered HTML of controls (although this can be mitigated with the CSS Control Adaptors, which will be built in to ASP.NET 4.0, and are the default behaviour I think).

Those are the main things for me that I really appreciate when building my MVC based sites.

Answer 2

In my honest opinion, you're looking at the wrong reasons to switch. Moving to ASP.NET MVC isn't going to fix any of these problems. It's still possible to have a giant view with as much, if not more, spaghetti code (or ball of mud) as classic ASP or Webforms.

Your talking points should be more along the lines of seperation of concerns, friendly URLs (available in Webforms too), more control over the page, etc.

You can check out this blog post from Microsoft too:

Web Forms vs. ASP.NET MVC

...take note of the phrase on the bottom of the page.

ASP.NET MVC is not the anti-Web Forms

They both have their proper uses. Switching to one from the other because of poor coding isn't going to help. You can do that in either one...

Answer 3

ASP.NET/webforms seems like (to borrow from Joel Spolsky) a "big leaky abstraction" of state over an essentially stateless medium. While this (I am told) was great for WinForms developers getting into web development, "Web forms" have always seemed to me a fundamentally flawed paradigm for this reason.

When I started to (recently) learn about web development (coming from a desktop background) I was introduced to it through Python/Django and RoR and I didn't really have any exposure to "classic" ASP.NET, webforms, or J2EE. I guess in my naivete I guess I just assumed all web development (or at least all large-scale web development) was based on the MVC pattern, it seemed such a natural fit for the web. Coming up against "classic" ASP.NET in the wild has been.. eye-opening o_O

Assuming you have any choice in the matter why would you not want to use ASP.NET MVC?

Answer 4

most of the developers I work with simply took the mess they complained about in classic asp and moved it to the code behind and "thought" this was a step in the right direction).

Well, it is a step in the right direction - better than no separation at all. Though, yes, it's still often a big ball of mud.

During my optimistic moments I think that well, maybe it does just move the ball-o-mud to the codebehind, but perhaps it plants the seeds of "hmm, maybe content should be separate from presentation!" in some minds. MVC or a similar model is of course the destination they'll eventually reach.

(Don't ask what I think during my NON-optimistic moments... haha.)

Answer 5

I want to caution you that the core problem you are reporting is not a technical one. With the kind of developers you describe (unmotivated, under-educated, or under-capable), I would suggest that you might consider NOT moving to the asp.net MVC framework.

The MVC framework will not solve the problems of a team that is slow to learn and utilize good design principals in their work. But the MVC framework in the current form will add a LOI of additional learning to their plates. The MVC framework doesn't have much in the way of RAD features, and using it correctly requires a deep understanding of the nature of Http itself.

A badly implemented MVC application is going to be a LOT worse than a badly implemented webforms application. With webforms, you can get by not understanding much about the deeper interactions of Http and such because the framework handles most of the state management itself.

With programmers like the ones you describe you are likely going to end up trying to teach them how to do OO design at the same time you are trying to also teach them the internals of Http AND get them to learn a whole new framework too.

That's hard enough with highly motivated and very capable programmers.