Whether you're an ASP .NET developer who works with data-based applications or a SQL Server DBA supporting ASP.NET applications, you'll find new capabilities in ASP.NET 2.0 to help you boost yourWeb site's performance.With the release of SQL Server 2005,Visual Studio 2005, and Microsoft .NET Framework 2.0, Microsoft continues to enhance its support at every tier of an ASP.NET application.At the client tier, ASP.NET 2.0 introduces callback functions that let you provide a dynamic, interactive application display without increasing roundtrips to the server. On the Web server tier, new page and partial-page caching options improve performance and give you more control over cache settings. And on the database tier, you can now create SQL Server dependencies to automatically invalidate cached data that the Web server is using.
Callback Functions
When a user makes changes within a Web page, the speed of your application's response affects that user's perception of your application's performance. But the amount of data you transmit to support those changes actually affects your application's scalability and performance.
In previous releases of ASP.NET, you enable a Web page's dynamic elements by sending the client a set of Java or JScript functions along with all the data those scripts should act on. For example, if you want to change the content of DropDownListBox B based on the user's selection in Drop-DownListBox A without making a server roundtrip, you send the client all possible options for DropDownListBox B along with the JScript code that will be called whenever a user selects something in Drop-DownListBox A. However, this approach has some significant performance limitations when you have a large list of potential options. You can't provide a truly interactive UI if you must download potentially thousands of bytes that the user might never access.
Instead, your client-side script needs to retrieve additional data into the client's desktop-based browser without needing to refresh the entire Web page.This technique, called Asynchronous JavaScript And XML (AJAX), originated years ago as part of custom enhancements to Microsoft Internet Explorer (IE). Over time, all major browsers implemented in some fashion the XMLHTTP object that Microsoft introduced, and Microsoft is now working on a robust set of AJAX-based tools called Atlas to support high-performance, interactive Web pages.The Web sidebar "Atlas Takes On the World," InstantDoc ID 50274, introduces Atlas, but as powerful as this toolset promises to be, it didn't ship with ASP.NET 2.0— callback functions did.
Callback functions in ASP.NET 2.0 let you request from your server additional data based on a user action. And rather than writing the JScript code to perform this functionality, you can leverage built-in ASP.NET 2.0 code that lets you retrieve data directly from the server without reposting the entire page to the client.
Callback functions use ASP.NET's ICallbackEventHandler interface. This interface defines two server-side methods that your ASP .NET page needs to implement to handle calls from a Web client back to your server page. Your page calls the first method, RaiseCallbackEvent(ByVal eventArgument As String), when the client's browser raises a callback event to your server.The code you use to call Raise-CallbackEvent must use the RaiseCallback-Event method name because ASP.NET looks only for a method with this name. In addition, the ASP.NET-generated code accepts a single string as the input parameter to this method, which then passes the string to the XMLHttpRequest object for processing. This method doesn't return anything—meaning that in C#, it's a void method, and in Visual Basic (VB), it's a Sub method.
YourWeb page then needs to implement the GetCallbackResult method, which the page calls to retrieve the result of the Raise-CallbackEvent method.This second method doesn't accept an input parameter, but it returns a string value, so you need some client code to parse and react to the returned string. For more complex operations—for example, those that populate a DataGrid—you want the returned string to contain XML that you can parse into the rows and columns of your grid.
You might think you need to add JScript functions to your page to implement these server-side methods for ASP.NET callback functions. But your page needs to perform only four steps to make a callback to the server and retrieve the results—and ASP.NET generates code for the first three steps for you.The four steps are
- Call back to the server with the data formatted as a string to trigger the server processing.
- Call back to the server to get the result of that processing.
- Call the client-side function you define, passing it the result so that the function can process it and display it on the page.
- Process the result in JScript or another client scripting language.
Let's look first at Step 4, which you need to have in place to generate the code for steps 1-3. In your Web page, you need a function that accepts two parameters: the result and a context (i.e., the name of the client script making the callback). For this example, let's call this function ProcessCallbackResult.The result parameter will contain the string returned from the callback.
Next, to generate the code for steps 1-3, you need to define as part of your page's loadevent-code the key end points for the callback processing. Step 1 is to get, at runtime, the address of your RaiseCallbackEvent method in your server page and pass it to the client page.This processing starts with a call to the shared (or static) methodPage.ClientScript .GetCallbackEventReference(). This overloaded method accepts the name of the ProcessCallbackResult function on the client along with three to five additional parameters that define your callback function.
The call to Page.ClientScript. GetCallbackEventReference() is important because you pass it the name of the client function you want called, and it returns a string that makes the callback, gets the callback result, then passes that result to your function.This code generation works because the two methods you define to implement the ICallbackEventHandler in your server code are limited by name and parameter types, letting .NET generate the necessary client code to call these server-side methods. I encourage you to review this functionality in more detail on the Microsoft Developer Network (MSDN) to see how to define error handlers on your client and other robust capabilities that are beyond the scope of this article. A good starting point—beyond the GetCallbackEventReference() method's Help page—is the MSDN article " Implementing Client CallbacksWithout Postbacks in ASP.NET Web Pages," at http://msdn2.microsoft.com/en-us/library/ms178208 (vs.80).aspx.