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 know that what makes MVC great is that is forces separation between the presentation layer and the business object or data layer along with its stateless operation. I also know that when you are working with the view, it appears that the code is less readable (see my example below).

So I guess my question is... If the separation is the concern, why not just separate.

Web Forms View Code:

//UI
<h2><asp:Label ID="lblPageHeader" runat="server" /></h2>

Web Forms Code Behind:

//CODE BEHIND
this.lblPageHeader.Text = myObject.Header;

MVC Code View:

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

MVC Controller Code:

index = new Index
{
    PageText = sb.ToString(),
    PageTitle = "WELCOME"
};
return View(index);

Again, I might be being stubborn, but one of the things that I really liked in WebForms is the ease in setting object properties like DataSources and Text values. It seems like this is completely different in MVC and less readable which makes me wonder about long term maintenance.

EDIT After looking into the typed models, I think the readability of the code is substantially improved.

Answer 1

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 2

Of course a simple example is going to be very clear and readable no matter how you do it. Supposedly, MVC's advantage becomes more apparent as you scale up the complexity.

Also, it turns out that the webforms model just isn't that great for high-volume public internet sites. ViewState plus the expensive page life cycle in a normal web forms site can make scalability a challenge (not impossible, but challenging). By contrast, on an intranet site users generally have much greater upstream bandwidth (ViewState works better) and volume is much better controlled. So webforms really works great there.

Answer 3

I'm also taking a wait-and-see attitude about ASP.NET MVC (along with the Entity framework and WPF for diff reasons). I'm a huge fan of MVC in general but am a little concerned about wrapping something as general purpose as a web development framework into the constraints of one pattern. A very useful pattern but still only 1 of many.

A skilled developer can implement MVC in practically any language. So MVC may be a great way to prevent less-skilled developers (we're all this at some point, like when just learning a framework) from making egregious mistakes. Since the pattern works well in a wide range of scenarios that could make it a net benefit.

On the other hand, for expert developers it may turn out to be like training wheels on an olympic cyclist... Redundant and more of a pain than a boon.

Answer 4

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: http://stackoverflow.com/questions/361910/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 5

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

Answer 6

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 7

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 8

I think it very much depends upon your background. If you're already familiar with something like Ruby-rails and/or Django, asp.net mvc makes much more sense.

Also if you have been doing websites in Html and css for a long time, Mvc is much better as you have full control over your html output.

If you're comfortable with asp.net just keep using that, it's not going away :).