Programming Microsoft ASP.NET 4 - Dino Esposito [316]
Chapter 15. The Model-View-Presenter Pattern
I have never let my schooling interfere with my education.
—Mark Twain
Generally speaking, creating the user interface of an ASP.NET Web Forms application is kind of easy. Even though I’m not sure the effort it takes to create a compelling and graphically appealing user interface should be referred to as “easy,” arranging the desired functionality is usually not a big deal thanks to the full bag of server controls you can get. If there’s a reason behind the success of ASP.NET, it’s likely the ease of development—a clear offspring of the Rapid Application Development (RAD) paradigm.
For many years, it was so easy (and quite effective) to drop a control on the Microsoft Visual Studio Web page designer, double-click, and fill in the method stub created for you in the page’s code-behind class. Therefore, a plain, old T-SQL query attached to the handler of, say, a Click event did the job of retrieving data and populating a grid after a user’s click. Like it or not, it was quick and effective—the beauty of RAD.
As the complexity of the application grows, RADness loses most of its appeal and stops being an ideal companion for the presentation layer. This is the biggest change in the software industry that we’ve gone through in the past few years. The need for a more structured way of writing software doesn’t mean, of course, we don’t need Visual Studio anymore. However, we probably need to consider Visual Studio designers for what they actually are—facilities for the UI rather than an aid for software design. (Visual Studio 2010 Ultimate does have a number of interesting facilities for design and modeling, but these tools cross-cut the platform you’re using for building the presentation.)
In Chapter 14, we reviewed layered applications and considered a number of patterns for the business and data access layers. In this chapter, we consider patterns for layering the presentation layer of applications with a particular eye to ASP.NET applications.
Patterns for the Presentation Layer
Your design of the presentation layer of any system should be driven by one fundamental principle: keep the presentation layer separated from anything else, including business and data access layers. Over the years, a few design patterns have been identified to help you with the presentation layer. We recognize three main families of patterns: Model-View-Controller (MVC), Model-View-Presenter (MVP), and Presentation Model (PM). The last one is more popularly known in the .NET space as Model-View-ViewModel (MVVM).
Not all of them can be applied to ASP.NET Web Forms with the same effectiveness. Actually, the design pattern that best applies to ASP.NET Web Forms applications is MVP, which will be the main topic of this chapter.
Before I go any further on that topic, you should note that these patterns span 30 years of computer design and programming. And many, many things have changed in the past 30 years. So, for example, what we call MVC today doesn’t exactly match the definition of MVC you find in the original paper that dates back about 30 years ago. To some extent, the same can be said for MVP. Two flavors of MVP exist—Passive View and Supervising Controller—and, in many applications, you actually use a personal mix of both. Likewise, even though PM and MVVM share the same architectural idea, MVVM is associated today with specific technologies such as Microsoft Silverlight, Windows Presentation Foundation (WPF), and Windows Phone.
This is to say that patterns like MVP and MVC give you quite a good idea of the approach behind a pattern, but details might change once the pattern is applied to a framework and a bunch of technologies. If you have a framework that gives you testability and separation