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

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