Why ASP. NET Ajax updatepanels is dangerous

[Original English address: http://encosia.com/why-aspnet-ajax-updatepanels-are-dangerous/]

[Indicate the source for reprinting at http://blog.csdn.net/donhao/article/details/7218088]

Like me, you can't resist placing many updatepanel on pages to prove the strength of Ajax. With updatepanel, you can easily implement Ajax without even having to know how the underlying layer is implemented.

Unfortunately, the interaction between the client and the server lacks transparency, and it is easy to stick to your own (or your own applications. Let me give you an example. I should be very familiar with it as follows:

<asp:UpdatePanel runat="server" ID="up1"> <ContentTemplate>   <asp:Label runat="server" ID="Label1" Text="Update Me!" /><br />   <asp:Button runat="server" ID="Button1"      Text="Postback Update" OnClick="Button1_Click" /> </ContentTemplate></asp:UpdatePanel>

protected void Button1_Click(object sender, EventArgs e){  Label1.Text = DateTime.Now.ToLongDateString();}

It's easy enough. Click button1 and get the current time through an asynchronous request. Then the time will be used as the content of label1. It looks very simple, but let's take a look at how the actual http post and response completes partial sending back:

Shocked, right? To display 22 characters, a considerable amount of data is sent and received. It is not a problem in features that are rarely used, but it will be worse when the usage is very high. Fortunately, Microsoft provides a more efficient way to implement it as part of the ASP. NET Ajax framework.

Page Method)

The page method allows the ASP. NET Ajax page to directly execute the static method of the page using JSON (JavaScript Object Notation. JSON can be seen as a simplified soap version, which is very suitable for lightweight communication between the client and the server. For how to implement the PAGE method and JSON, let's look at Microsoft's exposing
Web services to client script in ASP. NET Ajax.

Instead of returning and receiving HTML tags to replace all the content in updatepanel, we use the web method to request the information we are only interested in:

<asp:ScriptManager ID="ScriptManager1" runat="server"   EnablePageMethods="true" /><script language="javascript"> function UpdateTime() {   PageMethods.GetCurrentDate(OnSucceeded, OnFailed);  }  function OnSucceeded(result, userContext, methodName) {   $get('Label1').innerHTML = result;  }  function OnFailed(error, userContext, methodName) {   $get('Label1').innerHTML = "An error occured."; }</script><asp:Label runat="server" ID="Label1" Text="Update Me!" /><br /><input type="button" id="Button2" value="Web Method Update"   onclick="UpdateTime();" />

public static string GetCurrentDate(){  return DateTime.Now.ToLongDateString();}

In this way, we completely eliminate the http post data in the updatepanel request, and also reduce the response data to the request information we are only interested in:

When JSON is used, the whole HTTP request is sent back and forth to 24 bytes, Which is 872 higher than the 4000% bytes in updatepanel. As the page complexity increases, the performance will increase.

This not only significantly reduces the use of network bandwidth, but also the server does not need to instantiate the updatepanel control, so it does not need to maintain its lifecycle to send HTML back to the browser.

The simplicity of updatepanel is understandable, which is why we love updatepanel. However, in the case of high load, updatepanel is not a wise choice.