ASP.NET MVC > ASP.NET WebForms, Why?

Question

I\'ve now completed my first web application using ASP.NET MVC and overall, I still am not grasping why this is getting all the praise and glory. Maybe I\'m being stubborn. I k

Answer 1

Not a complete answer, but one big concern is testability of ASP.NET Forms, or the lack thereof. Testing the UI logic of what gets displayed and how. With ASP.NET Forms, you are left to just the codebehind.

Now, MVC isn't for everyone. You may want to look into MVP (Model-View Presenter) for ASP.NET Forms as it uses very similar MVC concepts, except the Presenter is in control of changing the view's internals.

But, testability is really a big plus for testing your code. Such as whawt happens when someone clicks the ChangePassword method/action:

[TestClass]
public class AccountControllerTest
{

    [TestMethod]
    public void ChangePasswordPostRedirectsOnSuccess()
    {
        // Arrange
        AccountController controller = GetAccountController();

        // Act
        RedirectToRouteResult result = 
            (RedirectToRouteResult)controller.ChangePassword(
                "oldPass", "newPass", "newPass");

        // Assert
        Assert.AreEqual("ChangePasswordSuccess"
            , result.RouteValues["action"]);
    }
}

Answer 2

One thing (out of many) that I like about MVC is that it gets rid of Web Server Controls. While they are seen by many as a great thing about WebForms, I have found that once you get past the basic operations they become a nightmare. Trying to juggle databinding events on grids with postbacks and everything else becomes the OO version of spaghetti code.

MVC will require you have a better knowledge of the basic tenants of web development (GET, POST, REQUEST, HTML, CSS, JAVASCRIPT), the result will be much better. See my graph of how I think MVC works :-)

alt text http://www.baseestate.com/webformsmvc.gif

Answer 3

What's great about ASP.NET MVC is that is doesn't try to hide how HTTP works. To fully understand ASP.NET MVC you need to understand the technologies of the web.

While webforms are adequate as long as you work to their strengths, they're ultimately a very leaky abstraction when you don't. While the drawbacks of viewstate have been well discussed by this point I think it's the extremely unwise attempt to mimic the behaviour of Winforms that is the underlying flaw - viewstate is merely a product of that.

The web controls which ship with ASP.NET also leave a (hell of a) lot to be desired as anyone who has tried to build an accessible website can attest to. The web controls show a total lack of understanding for how frontend development is done, and frankly are a disgrace.

With ASP.NET MVC all that nonsense is done away with. You're not shielded from HTTP, HTML, CSS, or JavaScript - if you come to the party with those technologies the framework gets out of the way and lets you leverage them. If not, then thankfully it doesn't try to help you to pretend they don't exist.

Answer 4

ASP.NET MVC Best Practices, Tips and Tricks

I would write:

<h2><%= Html.Encode(Model.Title) %></h2>

(it's possible with a help of typed views)

instead of

<h2><%= Html.Encode((MyApp.MyObject)ViewData["PageObject"].Header) %></h2>

I think it's all about how you use it. If you're more happy with classic ASP.NET, than maybe it will be a better idea to stick with it. Moreover, you could also take good stuff from ASP.NET MVC world (like UI and Logic separation) and bring it to the classic ASP.NET.

Answer 5

It's true that you need to do more in MVC to get some of the same basic VERY automatic functionality you became accustomed to in WebForms.

However, in the long run you end up with more control.

The main thing broken about WebForms is the whole PostBack scenario, and how many hoops you have to jump through to implement something simple WebForms didn't think of. One excellent example is my WebForms-related question: Is there any native way in ASP.NET to do a "success message"?

I wanted to make a "Record Saved" or "New Record Added" message in a WebForms application. Turns out you have to do some really scary stuff just to get this simple functionality to work, because they don't have a normal way to do this in WebForms, and to do a custom method, you're fighting against the hidden functionality in PostBack.

In MVC, this would be no problem. You'd still have to write the functionality manually, but you'd have much more control over your page state.

Answer 6

I believe you can only feel the difference after you've been in a big project and seen how much mess WebForms approach could cause.

When you've seen a page contains multiple components, user controls, some of them living independent lives like hiding/showing or enabling/disabling themselves, all these rules passing through multiple control layers which cannot be traced until you've been in a project for many long years (or at least have smoked something reeealy good before diving in with the debugger :) ), you begin to appreciate the possibility for a clearly defined flow of control when you see how your data defines what components with what properties are rendered on a page.

I've also loved WebForms for a long time. I also disliked first few weeks/months MVC for exactly same reasons you put forth. After I've done some coding and could compare the experience, I began to enjoy MVC.

Still, there are some areas where MVC approach would be much more complicated and create more mess than WebForms would.

It'll come with time. Not really a long time. :)