MSDN Magazine - July 2008 - (Page 51)

DINO ESPOSITO Cutting EdgE The HTML Message Pattern A true AJAX architecture is characterized by a neat separation between the presentation and service layers. As I discussed last month, the existence of an explicit contract between the AJAX front end and back end opens up a whole new world of programming possibilities but raises a number of architectural questions (see msdn.microsoft.com/magazine/cc546561). I covered client-side data binding and templates and discussed an implementation of the BrowserSide Templating (BST) pattern. I also briefly introduced the HTML Message (HTM) pattern as an alternative model for rendering the user interface of a Web client. This month I’ll provide an enhanced implementation of BST and compare it to HTM solutions. represents the intermediate layer between a JavaScript front end and a set of business services. It smooths the impedance mismatch between the two tiers by adding a security barrier to protect core services in a customer-to-business (C2B) scenario and massaging data to and from JavaScript objects. The key role played by the AJAX service layer in an AJAX architecture makes the issue of accommodating the HTML user interface based on raw data (the data returned by core services and massaged by the AJAX service layer) virtually unavoidable for architects and developers. How would you dynamically create and update a browser user interface based on raw JavaScript data? AJAX Service Layer Figure 1 Typical Multitier System with an AJAX Front End I’ll refer to the server-side part of a typical AJAX presentation layer as the AJAX service layer to distinguish it from the service layer that generally represents the point of contact between the presentation and middle tier in a standard multitier architecture. Figure 1 illustrates the model. The communication between the AJAX service layer and the client front end occurs through HTTP endpoints that are exposed by Windows® Communication Foundation (WCF) services and are invoked by JavaScript proxy classes embedded in client pages. Especially when ASP.NET AJAX is the reference platform, designing and consuming services in the AJAX service layer is not a big deal. The trouble begins when you create or update the user interface. In particular, you need powerful tools, such as JavaScript-based data binding and templates, to manipulate data on the client effectively. In this context, ASP.NET partial rendering is only a shortterm solution that doesn’t imply a real architectural shift. However, ASP.NET partial rendering saves you from generating the user interface programmatically. Partial rendering preserves the view state and server page lifecycle and allows you to declaratively design the user interface using controls and properties. Such a model is still probably the best option for relatively simple Web sites, but I doubt it can be effective in an enterprise scenario where the AJAX front end is just the top tier of a deeper serviceoriented system. As shown in Figure 1, the AJAX service layer Years of work with ASP.NET server controls may have blurred the notion of what’s really needed to build an HTML user interface. If you’ve had exposure to custom control development, you probably remember that it is all about accumulating HTML markup in some buffer and then outputting it to the response stream. There’s no other way around this general pattern. Enhancements exist only to make it less error prone and more manageable. So the buffer where the HTML is accumulated may be a plain memory stream where you write HTML literals or a more sophisticated hierarchy of components each of which abstracts out a chunk of HTML. In classic ASP.NET, the response of a Web page is obtained by composing a control tree that is then recursively visited. Each member of the tree receives a stream where it writes down its own HTML markup. In an AJAX model, the response of a request may be raw data serialized as JavaScript Object Notation (JSON), XML, syndication, or whatever else you like, as well as HTML generated on the server. The BST pattern refers to a situation when a request brings raw data back to the client. The HTM pattern refers to a situation in which the request carries back ready-to-display markup. Send your questions and comments for Dino to cutting@microsoft.com. Code download available at msdn.microsoft.com/magazine/cc135911. July 2008 51 General Pattern for an HTML UI http://msdn.microsoft.com/magazine/cc546561 http://msdn.microsoft.com/magazine/cc135911

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

MSDN Magazine - July 2008 Contents Toolbox CLR Inside Out Flex Your Data Data Points Advanced Basics Office Space Cutting Edge Data Services ADO.NET Data and WPF Transactions WCF P2P Test Run Security Briefs Foundations .NET Matters {End Bracket}

MSDN Magazine - July 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.