[asp.net] Biggest advantage to using ASP.Net MVC vs web forms

What are some of the advantages of using one over the other?

MVC Controller:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

MVC View:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

How hard is that? No ViewState, No BS Page life-cycle...Just pure efficient code.

1. Proper AJAX, e.g. JSONResults no partial page postback nonsense.
2. no viewstate +1
3. No renaming of the HTML IDs.
4. Clean HTML = no bloat and having a decent shot at rendering XHTML or standards compliant pages.
5. No more generated AXD javascript.

Web forms also gain from greater maturity and support from third party control providers like Telerik.

In webforms you could also render almost whole html by hand, except few tags like viewstate, eventvalidation and similar, which can be removed with PageAdapters. Nobody force you to use GridView or some other server side control that has bad html rendering output.

I would say that biggest advantage of MVC is SPEED!

Next is forced separation of concern. But it doesn't forbid you to put whole BL and DAL logic inside Controller/Action! It's just separation of view, which can be done also in webforms (MVP pattern for example). A lot of things that people mentions for mvc can be done in webforms, but with some additional effort.
Main difference is that request comes to controller, not view, and those two layers are separated, not connected via partial class like in webforms (aspx + code behind)

My 2 cents:

• ASP.net forms is great for Rapid application Development and adding business value quickly. I still use it for most intranet applications.
• MVC is great for Search Engine Optimization as you control the URL and the HTML to a greater extent
• MVC generally produces a much leaner page - no viewstate and cleaner HTML = quick loading times
• MVC easy to cache portions of the page. -MVC is fun to write :- personal opinion ;-)

My personal opinion is that, Biggest dis-advantage to using ASP.Net MVC is that CODE BLOCKS mixed with HTML...
html hell for the developers who maintain it...

Main benefit i find is it forces the project into a more testable strcuture. This can pretty easily be done with webforms as well (MVP pattern), but requires the developer to have an understanding of this, many dont.

Webforms and MVC are both viable tools, both excel in different areas.

I personally use web forms as we primarily develop B2B/ LOB apps. But we always do it with an MVP pattern with wich we can achieve 95+% code coverage for our unit tests. This also alows us to automate testing on properties of webcontrols property value is exposed through the view eg

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

) I dont think this level of testing is as easily achived in MVC, without poluting my model.

MVC lets you have more than one form on a page, A small feature I know but it is handy!

Also the MVC pattern I feel make the code easier to maintain, esp. when you revisiting it after a few months.

In webforms you could also render almost whole html by hand, except few tags like viewstate, eventvalidation and similar, which can be removed with PageAdapters. Nobody force you to use GridView or some other server side control that has bad html rendering output.

I would say that biggest advantage of MVC is SPEED!

Next is forced separation of concern. But it doesn't forbid you to put whole BL and DAL logic inside Controller/Action! It's just separation of view, which can be done also in webforms (MVP pattern for example). A lot of things that people mentions for mvc can be done in webforms, but with some additional effort.
Main difference is that request comes to controller, not view, and those two layers are separated, not connected via partial class like in webforms (aspx + code behind)

You don't feel bad about using 'non post-back controls' anymore - and figuring how to smush them into a traditional asp.net environment.

This means that modern (free to use) javascript controls such this or this or this can all be used without that trying to fit a round peg in a square hole feel.

If you're working with other developers, such as PHP or JSP (and i'm guessing rails) - you're going to have a much easier time converting or collaborating on pages because you wont have all those 'nasty' ASP.NET events and controls everywhere.

You don't feel bad about using 'non post-back controls' anymore - and figuring how to smush them into a traditional asp.net environment.

This means that modern (free to use) javascript controls such this or this or this can all be used without that trying to fit a round peg in a square hole feel.

Biggest single advantage for me would be the clear-cut separation between your Model, View, and Controller layers. It helps promote good design from the start.

The problem with MVC is that even for "experts" it eats up a lot of valuable time and requires lot of effort. Businesses are driven by the basic thing "Quick Solution that works" regardless of technology behind it. WebForms is a RAD technology that saves time and money. Anything that requires more time is not acceptable by businesses.

Anyone old enough to remember classic ASP will remember the nightmare of opening a page with code mixed in with html and javascript - even the smallest page was a pain to figure out what the heck it was doing. I could be wrong, and I hope I am, but MVC looks like going back to those bad old days.

When ASP.Net came along it was hailed as the savior, separating code from content and allowing us to have web designers create the html and coders work on the code behind. If we didn't want to use ViewState, we turned it off. If we didn't want to use code behind for some reason, we could place our code inside the html just like classic ASP. If we didn't want to use PostBack we redirected to another page for processing. If we didn't want to use ASP.Net controls we used standard html controls. We could even interrogate the Response object if we didn't want to use ASP.Net runat="server" on our controls.

Now someone in their great wisdom (probably someone who never programmed classic ASP) has decided it's time to go back to the days of mixing code with content and call it "separation of concerns". Sure, you can create cleaner html, but you could with classic ASP. To say "you are not programming correctly if you have too much code inside your view" is like saying "if you wrote well structured and commented code in classic ASP it is far cleaner and better than ASP.NET"

If I wanted to go back to mixing code with content I'd look at developing using PHP which has a far more mature environment for that kind of development. If there are so many problems with ASP.NET then why not fix those issues?

Last but not least the new Razor engine means it is even harder to distinguish between html and code. At least we could look for opening and closing tags i.e. <% and %> in ASP but now the only indication will be the @ symbol.

It might be time to move to PHP and wait another 10 years for someone to separate code from content once again.

MVC lets you have more than one form on a page, A small feature I know but it is handy!

Also the MVC pattern I feel make the code easier to maintain, esp. when you revisiting it after a few months.

If you're working with other developers, such as PHP or JSP (and i'm guessing rails) - you're going to have a much easier time converting or collaborating on pages because you wont have all those 'nasty' ASP.NET events and controls everywhere.

I have not seen ANY advantages in MVC over ASP.Net. 10 years ago Microsoft came up with UIP (User Interface Process) as the answer to MVC. It was a flop. We did a large project (4 developers, 2 designers, 1 tester) with UIP back then and it was a sheer nightmare.

Don't just jump in to bandwagon for the sake of Hype. All of the advantages listed above are already available in Asp.Net (With more great tweaks [ New features in Asp.Net 4 ] in Asp.Net 4).

If your development team or a single developer families with Asp.Net just stick to it and make beautiful products quickly to satisfy your clients (who pays for your work hours). MVC will eat up your valuable time and produce the same results as Asp.Net :-)

I can see the only two advantages for smaller sites being: 6) RESTful urls that enables SEO. 7) No ViewState and PostBack events (and greater performance in general)

Testing for small sites is not an issue, neither are the design advantages when a site is coded properly anyway, MVC in many ways obfuscates and makes changes harder to make. I'm still deciding whether these advantages are worth it.

I can clearly see the advantage of MVC in larger multi-developer sites.

Modern javascript controls as well as JSON requests can be handled much easily using MVC. There we can use a lot of other mechanisms to post data from one action to another action. That's why we prefer MVC over web forms. Also we can build light weight pages.

Francis Shanahan,

1. Why do you call partial postback as "nonsense"? This is the core feature of Ajax and has been utilized very well in Atlas framework and wonderful third party controls like Telerik

2. I agree to your point regarding the viewstate. But if developers are careful to disable viewstate, this can greatly reduce the size of the HTML which is rendered thus the page becomes light weight.

3. Only HTML Server controls are renamed in ASP.NET Web Form model and not pure html controls. Whatever it may be, why are you so worried if the renaming is done? I know you want to deal with lot of javascript events on the client side but if you design your web pages smartly, you can definitely get all the id's you want

4. Even ASP.NET Web Forms meets XHTML Standards and I don't see any bloating. This is not a justification of why we need an MVC pattern

5. Again, why are you bothered with AXD Javascript? Why does it hurts you? This is not a valid justification again

So far, i am a fan of developing applications using classic ASP.NET Web forms. For eg: If you want to bind a dropdownlist or a gridview, you need a maximum of 30 minutes and not more than 20 lines of code (minimal of course). But in case of MVC, talk to the developers how pain it is.

The biggest downside of MVC is we are going back to the days of ASP. Remember the spaghetti code of mixing up Server code and HTML??? Oh my god, try to read an MVC aspx page mixed with javascript, HTML, JQuery, CSS, Server tags and what not....Any body can answer this question?

ASP.NET Web Forms and MVC are two web frameworks developed by Microsoft - they are both good choices. Neither of the web frameworks are to be replaced by the other nor are there plans to have them 'merged' into a single framework. Continued support and development are done in parallel by Microsoft and neither will be 'going away'.

Each of these web frameworks offers advantages/disadvantages - some of which need to be considered when developing a web application. A web application can be developed using either technology - it might make development for a particular application easier selecting one technology versus the other and vice versa.

ASP.NET Web Forms:

• Development supports state • Gives the illusion that a web application is aware of what the user has been doing, similar to Windows applications. I.e. Makes 'wizard' functionality a little bit easier to implement. Web forms does a great job at hiding a lot of that complexity from the developer.
• Rapid Application Development (RAD) • The ability to just 'jump in' and start delivering web forms. This is disputed by some of the MVC community, but pushed by Microsoft. In the end, it comes down to the level of expertise of the developer and what they are comfortable with. The web forms model probably has less of a learning curve to less experienced developers.
• Larger control toolbox • ASP.NET Web Forms offers a much greater and more robust toolbox (web controls) whereas MVC offers a more primitive control set relying more on rich client-side controls via jQuery (Javascript).
• Mature • It's been around since 2002 and there is an abundance of information with regards to questions, problems, etc. Offers more third-party control - need to consider your existing toolkits.

ASP.NET MVC:

• Separation of concerns (SoC) • From a technical standpoint, the organization of code within MVC is very clean, organized and granular, making it easier (hopefully) for a web application to scale in terms of functionality. Promotes great design from a development standpoint.
• Easier integration with client side tools (rich user interface tools) • More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.
• Search Engine Optimization (SEO) Friendly / Stateless • URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.
• Works well with developers who need high degree of control • Many controls in ASP.NET web forms automatically generate much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, it lends itself better towards having complete control with what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.
• Test Driven Development (TDD) • With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.

Authentication, authorization, configuration, compilation and deployment are all features that are shared between the two web frameworks.