ASP.NET webforms + ASP.NET Ajax versus ASP.NET MVC and Ajax framework freedom

Question

If given the choice, which path would you take?

ASP.NET Webforms + ASP.NET AJAX

or

ASP.NET MVC + JavaScript Framework of your Choice

Are there any limitations that ASP.NET Webforms / ASP.NET AJAX has vis-a-vis MVC?

Answer 1

I love webforms, but ASP.NET AJAX is a pile of crap.

I prefer to use WebForms + custom HTTPHandlers handling the server side of any AJAX calls.

Heh, downvoted...

ASP.NET AJAX Is a pile of crap because a callback requires the entire page class to be reinstantiated, you aren't calling a single method, you are rebuilding the entire page on the server everytime.

Also, UpdatePanels return the entire page, only the section in the update panel is popped in, its a total waste of bandwidth.

I understand why its done this way, because WebForms controls can't really be easily other ways, but it still is really lousy.

Answer 2

I've used asp.net winforms with ajax.net as well as prototype/ext/jquery. I guess something to consider is the goal of the site.. MVC is a popular pattern. I can't say anything against ASP MVC because I haven't had a chance to use it, but I want to make sure you know you are not limited to just ajax.net if you chose webforms.

Answer 3

ASP.NET MVC is still in "Preview" form, and as such I wouldn't consider it until it matures. You can roll-your-own MVP pattern pretty easily without much plumbing.

On the Ajax front, I'd say try to find libraries (commercial or otherwise) that do what you're looking for. The basics (Grids, trees, autocomplete textboxes, etc.) have been done to death. Don't Reinvent The Wheel.

Answer 4

I've done both lately, I would take MVC nine times out of ten.

• I really dislike the implementation of the asp.net ajax controls, I've run into a lot of issues with timing, events, and debugging postback issues. I learned a lot from http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
• The asp.net project we used the MVP pattern http://www.codeplex.com/aspnetmvp, and the pattern worked great. However we ended up with a lot of code in the view because we were directly interacting with the server side controls (i.e a lot of gridview manipulations). This code is nearly untestable with the unit test frameworks. We should have been more diligent about keeping code out of the view, but in some instances it was just easier and less messy.

The one time I would choose using asp.net forms development would be to use the gridview control. We are using jquery for our javascript framework with MVC and have not yet found a very good gridview like control. We have something that is functional, but the amount of time we have sunk into learning, tweaking, and debugging it vs using asp.net server side controls has been substantial. One looses all of the nice widgets Microsoft provides out of the box doing non asp.net form development. The loss of those widgets is freeing, and scary at the same time when you first start.

At the end of the day I'm happy we are doing MVC development. My team and I have learned a new framework, (we were only asp.net developers before), and have gotten our hands dirty with html and javascript. These are skills we can take onto other projects or other languages if we ever need to.

Answer 5

When I am designing a site one of the big things I prefer is the DRY principle. IMO ASP.NET MVC is much more dry than web forms.

I have recently made the move from webforms to MVC and I hope I never have to go back!

Answer 6

Webforms with ASP.NET Ajax is heaven. The integration between the 2 is just amazing and feels so natural to work with.

Using webforms instead of mvc will give you the ability to utilize the lifecycle to develop very good and re-usable controls.

But I still like to add a little jQuery into the mix for traversing the dom and adding animations, I just like to use asp.net ajax to get the integration with the server side.

Answer 7

I agree that asp.net ajax UpdatePanels are not an ideal solution.

We have avoided using them and instead have been using the client-side libraries to do any communication with the server. I do like what I saw at PDC about the features coming in asp.net ajax 4.0 with declarative components and client-side templating - very nice! Combining JQuery with the existing libraries provides quite a bit - and I have questioned using JQuery exclusively instead given it's much smaller footprint and it's ability to do a lot of the same things as the asp.net ajax client library.

As far as the server stack - I haven't used MVC yet, but we have had success using a home-rolled MVP approach using webforms.

Answer 8

The concept behind MVC is great, but be prepared to loose virtually all the functionality of all the server controls you've used for so many years. I've only looked at the MVC implementation for about a week now, but the page lifecycle and view state are gone so these controls no longer function properly.

I was also stunned to find a number of examples containing a lot of logic code in the markup. That's right, 'if' and 'foreach' statements in the aspx files -- a horrible step backwards imho. I was very happy to leave classic asp behind but in the current implementation of the asp.net mvc pattern you're back to code in your markup, the need to use helpers everywhere, and the lack of virtually any useable server controls.

If you're starting a new project now I'd recommend sticking with asp.net webforms and make use of a the built in asp.net ajax, the toolkit, and jQuery as needed. The asp.net ajax implementation may not be the absolute best, or most efficient implementation, but unless you're getting a million uniques on day 1 or your server is a commodore vic 20 the performance hit isn't going to be that noticeable.

This of course does depend on your project size. If you're starting a 5 year Enterprise level application that expect millions of page views, UpdatePanel might not cut it, but if you're building an average site, throwing up a prototype, or just need to get moving fast, asp.net ajax works perfectly fine and has an extremely low learning curve.

And to be clear, the entire page is absolutely not returned every time an ajax call is made. /Only/ the content for the panel that needs to be updated is sent across the wire. Any http monitor will prove this point. Yes, the page /lifecycle/ is performed, but knowing that you can can build fairly efficient asp.net ajax applications.

Answer 9

If you need update panel, I suggest you to use open source and lite MagicAjax or ComfortASP. If you need framework helps developing custom ajax, I suggest jQuery.

Answer 10

Don't let people fool you into thinking that it is a clear cut choice. You can get the best of both worlds. My approach is to create an MVC project, but instead of adding views, add standard asp.net pages, but change the code behind to inherit from MVC.ViewPage like so:

public partial class SamplePage : System.Web.Mvc.ViewPage
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

If you confine yourself to the single form tag (with runat="server") in the code in front, then you have full code behind access to your standard asp.net server controls. This means you get full server side control of the presentation (eg. using databinding and repeaters) without having to do that old ASP-style code weaving.

    protected void Page_Load(object sender, EventArgs e)
    {
        IObjectDefinition instance = (IObjectDefinition)ViewData["definition"];
        _objectName.Text = instance.DisplayName;//textbox or label

        DataTable itemVals = new DataTable();
        itemVals .Columns.Add("itemName");
        itemVals .Columns.Add("itemValue");            


        IDictionary<string, string> items = (IDictionary<string, string>)ViewData["items"];
        foreach (KeyValuePair<string, string> datum in items)
        {
            conditions.Rows.Add(new object[] { datum.Key, datum.Value});
        }

        _itemList.DataSource = itemVals;//repeater
        _itemList.DataBind();
    }

The post for any control does not post back to the page, but to the controller. If you remember to use the name property on your server controls then they end up in the FormControls collection for access to your page variables as per standard MVC.

So what do you get?:

• full server side control of presentation your code in front is purely HTML and asp.net server control tags
• full separation of concerns - the page does presentation only, and all orchestration and marshalling is done in the controller (rather than asp.net style in the page)
• full MVC testability
• No html code weaving
• You can tunr view state off and reduce page bloat

What do you lose?

• Once again you are confined to one form per page if you want to use only server controls
• You may need to manually specify postback targets for buttons and the form
• You once again have 2 files for your presentation

Oh, and for AJAX - jQuery definitely. Making a request to a controller method that returns a JsonResult really simplifies things.

Answer 11

I see that the majority of the responses came out prior to MVC 1.0. Since we are now in 2.0 Preview, I thought it might nice to revisit.

I was a ASP.NET developer for about five years before I made the move to MVC last March. I haven't regretted it for a second. I realize now that the stronger I got in ASP.NET WebForms, the more difficult it became to learn other technologies, such as JavaScript and the non-Microsoft implementation of AJAX. Microsoft leveraged their ASP.NET development approach from their WinForms development approach, which helped with the learning curve if you were coming from WebForms development, but it's not a good way to develop web applications if you understand the differences between the two approaches.

The latest project I'm working required me to learn ASP.NET MVC, JavaScript, jQuery, CSS 2, and AJAX (non-Microsoft). After only nine months, I feel much better prepared to approach web development projects than I did after five years of ASP.NET development. The ASP.NET implementation makes things so much more difficult to maintain long-term. MVC makes things so much easier, because you're less dependent on shortcuts. It takes a while to learn the framework, but the more you learn about the framework, the less dependent on the framework you become and the more you start to learn and understand the established standards, like JavaScript and AJAX.

For me, it is a clear-cut choice. I will never go back to ASP.NET. If I can't use ASP.NET MVC, I'll learn Ruby or PHP. I want the progress and advancement of my web development tools to be motivated by the needs of the developer community, not by profit.

Answer 12

My experience has been with programming web apps for apache servers in php and ruby. When I got a job maintaining a web app written in asp.net (webforms), I dove into learning the microsoft way of building web apps. I will have to say I was completely mortified! I was thinking WTF is all this viewstate garbage being sent back in forth? Is this even necessary?

And then I decided to look at doing some simple things with ajax and jquery, which lead me to update panels and clientIDs being generated, and not what I set in the view. What a waste of my time! Why can't I have multiple forms on one page? Why can't I just use regular ajax calls? Why do my views have server logic? These were all questions that im sure that many web programmers face with asp.net webforms. Then, I discovered .NET MVC. My life just got a lot easier.

I was used to using MVC frameworks like Rails and CakePHP to create web apps the way they were meant to be programmed. With technologies actually meant for the web.

My suggestion would be this, Leave WebForms for people that are used to programming winforms type applications because it tries to abstract the fact that you are programming on the web. If you want to have real freedom to develop applications for the web which actually make sense to web programmers, use .NET MVC or something similar that wont get in your way.

Thats my two cents...

Answer 13

to compliment @ben's answer, I used ASP.Net webforms for simple databinding, and JQuery for all Ajax transactions. To be honest, I still couldn't let go of databinding because of its simplicity. Viewstate is almost useless so I basically turn it off. You can use MVC though, but be warned, it will take most of your time developing functionality that you take for granted in Forms. Good luck man!

Answer 14

It's been a long time since the original question. Now we have MVC3 and .NET 4

Is MVC now a better solution than before?