MSDN Magazine - June 2008 - (Page 27)

data and layout information. Moreover, data is merged with the surrounding markup and can’t be separated from it. Finally, if you have other similarly functioning updatable panels on the page, the timer may stop for a while if another partial rendering operation is started in the meantime. Or it may stop another pending operation when the timer triggers. In the end, while it is quick to learn and apply, partial rendering is not the ideal mechanism to employ when you need to support simultaneous asynchronous calls. Let’s see what it takes to rewrite the page in Figure 2 using a pure AJAX approach. Figure 3 Live Quote Web Service namespace Samples.WebServices { [WebService(Namespace = "http://samples.ajax/")] [ScriptService] public class LiveQuoteService : System.Web.Services.WebService { private static string stocks = ConfigurationManager.AppSettings["StockSymbols"]; private static StockPicker picker = new StockPicker(stocks); public LiveQuoteService() { } [WebMethod] public StockInfoCollection Update() { return picker.Update(); } [WebMethod] public string GetServiceDescription() { return picker.GetServiceDescription(); } Reconsidering the Live Quote Page How would a pure AJAX approach affect the design of a live quote page? The page sets up the timer and uses XMLHttpRequest to invoke a remote service. The service is part of the application back end and will use the standard Microsoft® .NET Framework API to call the finance Web service and get data. The data will then be returned to the browser as a JavaScript object. Finally, it’s up to you to render it to the user. What’s the difference? Firstly, the invoked URL is not the page itself. The page invokes an HTTP endpoint backed by a scriptable Web or WCF service. There’s no page lifecycle, no postback events, no view state restoration. As a result, network traffic is significantly reduced. In the case of this sample page, the payload is 10 times smaller than it is with partial rendering. From an architectural standpoint, you see two neatly separated blocks of code at work— the client-side front end and the server-side back end. The former is powered by JavaScript; the latter is based on managed code. ASP.NET AJAX shines in this context as it manages to unify the programming interface and data types so that the JavaScript client developer sees exactly the same programming interface and contracts that have been defined on the server. The JavaScript Object Notation (JSON) layer ensures that DTOs that arrive to the client mirror the data sent out from the server. Let’s experiment with some code. The new page has a client button that the user clicks to download fresh data. I’m using a button here instead of a timer only for convenience: } } way by an HTTP proxy or even by the JavaScript code running in the browser. More importantly, you’re not caching markup; you’ll be caching usable data (objects or JSON strings) that can be checked at any time against runtime conditions. Moving rendering logic to the client is beneficial also because it makes life easier for a busy server. The server saves CPU cycles and memory if it only has to return a small chunk of data and does not have to execute a full page lifecycle with markup generation and view state processing. It is equally straightforward to use ASP.NET AJAX from the client to interact with remote services and bring down live data to the browser. For example, the following is the code to invoke a remote method: function _getLiveQuotes() { Samples.WebServices.LiveQuoteService.Update(onDataAvailable); } function onDataAvailable(results) { // Update the UI } The JavaScript handler then invokes a method on a wrapper live quote Web service and gets a collection of StockInfo objects: ASP.NET AJAX gives you a JavaScript proxy object with the same name as the server-side service and a bunch of static meth- The full source code for the service is shown in Figure 3. In partial rendering, there’s no natural separation between the user interface elements (the view) and the core application logic (the model). Everything is assembled on the server and served ready-to-use to the client. With a pure AJAX architecture, the presentation layer is smarter, richer, and physically separated from the business layer. It goes without saying that such a highly decoupled architecture is inherently more flexible and easy to test. In addition, you have a few more places where you can cache data, as shown in Figure 4. Data can be cached on the server, care of the (Web) service front end and implementation. In addition, data can be cached along the msdnmagazine.com Figure 4 Possible Levels of Caching in an AJAX Architecture June 2008 27 http://msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.