MSDN Magazine - December 2008 - (Page 29)

DINO ESPOSITO Cutting EdgE ASP .NET Presentation Patterns In a layered Web app, the presentation layer is just as important as navigation logic, business logic, and data access. While you should try to keep the presentation layer (mostly the presentation logic) independent from the UI technology and platform, it’s not always easy to do. Design patterns can help. In this month’s column, I’ll examine some design patterns for building an ASP.NET presentation layer. I’ll start with the Model-View-Controller (MVC) pattern—the root of all patterns specifically targeted to the UI—and discuss its applicability to ASP.NET beyond the ASP.NET MVC Framework. An ASP.NET presentation layer is composed mostly of .aspx pages that are orchestrated by the HTTP runtime environment. A typical .aspx page, at some point, may place an HTTP request following a certain user’s action (such as a button click or a list selection). In ASP.NET Web Forms programming, these events are usually handled by methods—event handlers—written in the codebehind class of the page. At first glance, it would appear that there’s a direct connection between the user action and the system’s reaction. While this may be true in desktop applications, it is not the case in ASP.NET. In ASP.NET, a lot of things happen in the time between a user click and the display of an updated page—regardless of whether or not you’re using AJAX. The flow of information is shorter, however, in ASP.NET applications that you build with the ASP.NET MVC Framework. Let’s consider a button click event. As a developer, you handle it by writing some code in the Button control’s Click event handler. The code goes in the page’s codebehind, like so: void Button1_Click(object sender, EventArgs e) { // Perform any required action } Inside an ASP.NET Event Handler The loosely defined pattern of the Model View Controller allows for discretion over implementation details. You could also organize the code that responds to the user’s activity in controllers and actions: void Button1_Click(object sender, EventArgs e) { // Static method bound to the user action ThisPageController controller = new ThisPageController(); controller.Button1Clicked(); } I’m assuming that each page has its own controller component and that each controller has a list of public methods logically bound to a possible user action. How would you let the controller know the state of the page and how the new view is generated? Button1_Click is invoked on the server after the user has clicked the button and the ASP.NET runtime has received and processed the corresponding HTTP request. The Button1_Click method is exposed by a class derived from System.Web.UI.Page. This class has access to UI controls. Here’s a simple change to the controller’s signature that would enable the controller to access any public element in the page: void Button1_Click(object sender, EventArgs e) { // Static method bound to the user action ThisPageController controller = new ThisPageController(this); controller.Button1Clicked(); } The controller’s signature now receives a reference to the current ASP.NET page—the view. The controller method performs its work and then simply updates server controls. The standard page lifecycle of ASP.NET will do the rest and produce the HTML for the browser. The Page Lifecycle You could place all the code for the required action here. Or, you could group all of this code in a static or instance method exposed by an object: void Button1_Click(object sender, EventArgs e) { // Static method bound to the user action ActionManager.Button1Clicked(); } Figure 1 shows the main steps in the page lifecycle. Whenever an ASP.NET request hits the Web server and an HTTP handler is found to service it, the steps outlined in the figure are performed. As you can see, the code for a simple click of a button is only a small fraction of the whole ASP.NET infrastructure. You’ll see in a moThis column is based on a prerelease version of the ASP.NET MVC Framework. All information is subject to change. Send your questions and comments for Dino to cutting@microsoft.com. December 2008 29

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

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

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