views:

2997

answers:

14

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?

+6  A: 

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.

FlySwat
Now I'm curious. What would a sample implementation of WebForms + ASHX be like?
Bullines
You aren't limited to ASHX with the handler implementation, you can group handlers in class files and add the handlers to your webconfig. Very efficient as well but it depends on what you want to accomplish. A for instance would be to make an call with limited overhead to lock a record in a DB.
Quintin Robinson
Can you elaborate on "pile of crap"?
Jon Limjap
I agree that sending HTML instead of JSON is additional data over the wire. But its no more than moving between pages on a standard site. Also ASP AJAX gives webservice interaction, which is taking the result of a SOAP call and converting it to JSON. Thats pretty nice.
Owen
If you use WebMethods/PageMethods, you won't get the entire page.
Lurker Indeed
A: 

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.

Quintin Robinson
I wanted to clarify. I am looking forward to doing a MVC project just haven't had a spark to start one yet. Didn't want to sound like I was discouraging MVC development.
Quintin Robinson
+2  A: 

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.

Giorgio Galante
ASP.NET MVC may be in RC, but it's interesting to note that Stackoverflow is completely built upon ASP.NET MVC.
Notorious2tall
Sure, that doesn't mean I'd trust it for a system that's being used to pay the bills. StackOverflow.com, when it was started was just a plaything.
Giorgio Galante
+21  A: 

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.

ben
I agree with you, totally on this...good points :)
Marko
+2  A: 

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!

nbirkes
A: 

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.

sontek
My thoughts exactly, I hope the AJAX for MVC is as easy when I get around to learning it
Luke Lowrey
A: 

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.

mdarnall
+1  A: 

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.

Mike
Re: UpdatePanels, that is not remotely accurate. Even sites serving only a single concurrent user see massive performance increases when replacing UpdatePanels. You have to care very little about your users' experience on your site to use them in production.
Dave Ward
Interesting perspective on ASP.NET MVC ... we are starting a new project and almost went with ASP.NET, but none of us could understand how to use it (our team has HTML, winforms, and some PHP background, but nobody knew ASP.NET). For whatever reason, ASP.NET MVC seemed MUCH more natural since it closely related to the end product instead of trying to make everything look like winforms.
Jess
That's a good point - I should clarify - if you have virtually no asp.net background, MVC is probably the way to go. The pattern is sound and logically it makes a lot of sense. Not having the page lifecycle is great *IF* you haven't worked with it for years. I'm simply frustrated because my bag of tools no longer works and I don't have time to make a new bag.
Mike
first: yes, there are examples of mixing it up logic and ui, but those are bad examples, and sorry, it is funny to use it as an argument...second: if we talk about nature of web, we can say it is stateless..so viewstate is kind of workaround to persist state of pages.. :)finally: mvc is very nice and natural framework, you should try it again, for sure :)cheers
Marko
Your argument about server controls and the lack of them is valid and I thought that will be problem for me too but it proved not to be because so far I was able to replace almost everything with functionality from jQuery/jQueryUI and in many cases you can do it even better.
mare
One more thing to note is, I will never forget those moments when my DataGrid and Repeaters and other WebForms controls just stopped working - most of the times because something in HTML got corrupted or VS itself corrupted it or by some strange reason all of the events that were wired up dissappeared and all of a sudden I was left with a Edit and Delete links that were not working (i.e. posting back to the server because event registration was gone).
mare
+2  A: 

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.

dynback.com
+4  A: 

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.

Mike
A novel approach. I'm surprised none of the resident ASP.NET experts have weighed in.
Dirk
+7  A: 

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.

Neil T.
I must say I followed almost exactly the same path as you and I would never go back to ASP.NET WebForms again either. So far in the last few months I learned (still do) JS, jQuery (so-so), more about HTML and HTTP standards (which I thought I knew well but I knew almost nothing about the insides) and it is so much easier to do things like partial rendering, AJAX posts/gets, pure HTML control, just everything. MS hid everything from us with WebForms - and it was nice technologies and I liked it but from now on I'm going to only maintain it but develop new things in MVC.
mare
+1  A: 

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

Nik
Although less experiences, I used to program web based logic using Perl. I went some way into PHP after that, and then got into ASP. I have to say the way Microsoft feel the need to 'micromanage' everything is a royal pain in the ass. I very much like C# as a language though, and writing the business logic is a joy to behold. Making it interact with the actual web page is a nightmare. All this is because MS think it makes the whole thing more secure (and can sell it to business managers that way).I've not touched MVC but going by what I've heard, I need this in my life!
AlexW
A: 

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!

Martin Ongtangco
A: 

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?

RichardAlan
I answered this question back in February. Today, after looking deeply at MVC2 and briefly at MVC3, I chose to stay with MVC1. For me, I didn't want to fall in the trap originally set by WebForms. I want to become a better web developer, not a better ASP.NET MVC developer. I want to get closer to the HTML/CSS/JS standards, rather than continue to be wrapped up with Microsoft abstraction. I'm using jQuery and JavaScript much more than I did a year ago. My dependence on MVC server tags has reduced significantly, because I simply don't require them. My pages are comparatively smaller. Why switch?
Neil T.