MSDN Magazine - December 2008 - (Page 30)

Event PreInit Control Initialization Event Init Viewstate Processing Posted Data Processing Event Load State Changed Events Postback Events Event LoadComplete Event PreRender HTML Rendering Event PreRenderComplete Viewstate Update Event SaveStateComplete Event Unload Button1_Click Invoked Presenter (MVP) pattern. I’ll briefly recall the basics of the MVC and MVP patterns. The Original MVC Pattern The MVC pattern was devised back in 1979 as an approach to move away from catch-all, autonomous front ends. An autonomous view is a class that displays content, maintains state information for the view, and incorporates the full logic to handle any user actions from start to finish. This code snippet lays the groundwork for an autonomous view: void Button1_Click(object sender, EventArgs e) { // Perform any required action. All the code you // need to handle the event goes here. A page // built in this way is an autonomous view. // MVC fights autonomous views. } Figure 1 The ASP.NET Page Lifecycle ment that the page lifecycle represents a fraction of the work that the ASP.NET runtime executes to service each request. Before the code in Button1_Click can execute, the ASP.NET runtime creates an instance of the Page class that holds the expected behavior for the requested URL. The Page class processes the request according to the steps in Figure 1 and uses your event handlers where appropriate. In the Button1Clicked method in a controller class, you should be able to access any of the controls in the page with the same syntax you would use in a plain codebehind event handler. But members that reference UI controls (say, TextBox1) are not public members on the Page class. How can you make them accessible to a controller? You can implement a custom interface on the codebehind class that includes public properties for the UI controls you intend to manipulate from within the controller. Here’s an example: public interface IThisPageView { TextBox TextBox1Property; } // In the codebehind class public TextBox TextBox1Property { get {return TextBox1;} } With such a monolithic view, you can hardly build a testable presentation layer that’s separate from the underlying layers. Applying the concept of Separation of Concerns (SoC) helps you to get the right combination of low coupling and high cohesion for any component, because it causes you to keep the various functionalities in their own layers rather than intermingled. Second, SoC makes it easier to implement a navigational workflow to decide which page comes next. The original paper describing the MVC approach, “How to Use Model-View-Controller,” is available at st-www.cs.uiuc.edu/users/smarch/ st-docs/mvc.html. If you’ve never read it, I suggest you have a look at it regardless of your familiarity with the MVC philosophy. Today, MVC is considered a pattern for building a presentation layer, but it was originally meant for building complete applications. It’s helpful to look at it in this light. MVC is a loosely defined pattern that gives the architect much discretion over implementation details. This is probably why so many variations of MVC exist. MVC splits the app into three parts—the model, the view, and Figure 2 A Sample Class Acting as the Controller for a Page public class ThisPageController { protected IThisPageView thePage; public ThisPageController(IThisPageView page) { thePage = page; } public void Button1Clicked() { // Get the text currently stored in control TextBox1 string text = thePage.TextBox1Property.Text; // Do something: i.e., turn to upper case string newText = text.ToUpper(); // Update the text in control TextBox1 _thePage.TextBox1Property.Text = newText; Figure 2 provides an example of the sample controller. In Button1Clicked, you do your regular ASP.NET Web Forms programming and determine the next view by simply updating the state of server controls. The logic of the page is now encapsulated in a separate class that can be developed separately from the page. This solution, though, is still tightly coupled to the controls in the page. Let’s consider a refinement that refers to the Model-View30 msdn magazine } } Cutting Edge http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

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.