Web Presentation Patterns

In: Columns > Behind the Curtain

By Jonathan Snook

Published on January 23, 2006

Patterns structure our lives, whether we think about them or not. A regular bedtime—and morning alarm and lunch time—makes your life easier by removing some of the guesswork.

Patterns play a part in Web application development, too. Design patterns are standard solutions to common problems in software design. Various patterns have been well-documented and allow us to learn and apply a proven methodology for development. It establishes a “design vocabulary” that can be shared between developers—a programming shorthand, as it were.

A popular book on the subject is 1995’s Design Patterns by the so-called Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. It covers 23 patterns for object-oriented software development. How they got the nickname is not entirely clear, but their book is one of the first and best resources on describing design patterns. An additional resource is Patterns of Enterprise Application Architecture by Martin Fowler. Fowler’s work is a mixture of specialized and generalized patterns.

Fowler covers the Model-View-Controller pattern as it pertains to Web development and also describes a few variations on page controller and front controller.

Model-View-Controller (MVC)

MVC was originally described for use in Smalltalk-80, an object-oriented language originally developed in the early 70s, and has been used for application development ever since. MVC’s premise is the separation of an application into three parts: the model, the view and the controller. The “model” is the data model. The “view” is the presentation layer—for example, the HTML or Flash interface that users see. The “controller” receives input and informs the model to make changes to its state. The view is then notified of the change in the model so that the view can be generated.

In a Web application, a request comes in via HTTP and is given to the controller. From here, there are many ways the model and the view can interact. In a passive approach, the controller passes information on to the model so that it may update itself. Then the controller calls the correlating view. The view then retrieves the current state from the model. The view is then sent back to the client in the HTTP response. Using the passive approach, the model has little interaction except to respond to the view with any requests for state information. A more active approach may have the model actually notify the view or other models.

The controller in a Web application can be handled in various ways. The two most popular approaches are the page controller and the front controller.

Page Controller

The page controller should be familiar to most Web developers. Essentially, each page in a site acts as a controller for one or just a few views. For example, a call to userlist.php would display a list of users and useredit.php would be responsible for add, edit and delete functions. Each action presents a slightly different view but are all related to the user.

In this scenario, the view and the controller tend to be more closely linked since the controller is designed to handle a specific set of views. The model is still separated into its own classes and called upon by the view.

Front Controller

In a front controller, all actions are routed through one central controller that uses a dictionary to determine which model to update or which view to request. This is an approach taken by many Web applications including WordPress and eZpublish.

In the front controller approach, the URL begins to look and act a lot like a command line and it can be tempting to use it that way. Harry Fuecks muses:

“To me, a direct consequence of promoting actions as first-class objects is we end up with people putting verbs in URLs like “http://example.com/item/1/delete”, which in turn leads to problems like this and implies tight coupling (between client and server) and RPC. GET is clearly labeled as “safe / read only” while putting a verb in a URL implies something is going to be done (which may or may not be safe);”

Remember that POST should be used for any action that changes the state of the model.

Considerations

Design patterns create an abstraction that can make implementation and reuse easier, but it is important to evaluate patterns as a tool.

“You have to feel the pain of a design which has some problem. I guess you only appreciate a pattern once you have felt this design pain. ... Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs.”
- Erich Gamma

The trick is not to implement as many design patterns as you can, but to choose the design pattern that is most appropriate when you see the need for abstraction.

Resources

There is a plethora of resources and code examples on the Web to get you started in design patterns. Here are a few places to start:

• Data & Object Factory: C# code samples
• A Conversation with Erich Gamma
  • Part I: How to Use Design Patterns
  • Part II: Erich Gamma on Flexibility and Reuse
  • Part III: Design Principles From Design Patterns
  • Part IV: Patterns and Practice
• Web Presentation Patterns, Microsoft; includes ASP.NET code examples
• Webpatterns.org
• phpPatterns
• WACT, a patterns-based framework for Web applications
• MVC and web apps: oil and water – A discussion on the use of MVC in Web applications

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Web Design, Programming, Scripting