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'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 2

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.