Adopting an appropriate technology and architecture is an extremely important consideration when embarking on a new web system. The characteristics of a project should impact a development teams choice of technology. This blog post focuses on the Model View Controller (MVC) architecture for web applications.

Model View Controller (MVC) dates back to 1978. It was invented by Trygve Reenskaug (Walther, 2010) and was part of the multi-windowed Smalltalk-80 interface developed at Xerox PARC (Sanderson, 2009) (Burbeck, 1992). MVC is currently increasing in popularity as an architecture for web applications (Sanderson, 2009).

An MVC application is divided into three parts:

• Model – The model contains the functional core of an application such as the business logic, validation, and data access logic. The aim of the MVC pattern is to un-couple the model from the view and the controller parts, thereby creating a situation where parts of the model are able to be reused by other applications (Anon., 2007). The Model implements the Observer pattern (Freeman et al., 2004).

• View – Views give the user a presentation of the model. In traditional MVC applications the view is able to get the data it needs directly from the model using the observer pattern (Freeman et al., 2004). The view implements the Composite pattern  (Freeman et al., 2004).

• Controller – Controllers mediate incoming input translating input into requests either on the model or on the view. Controllers are responsible for calling methods to perform operations on the model which will typically change the state of the model (Anon., 2007) (Sanderson, 2009). The view and the controller implement the strategy pattern (Freeman et al., 2004).

Figure 1: The Model View Controller Architecture (Anon., 2002)

Figure 1 depicts the traditional MVC architecture as implemented in many traditional software development systems. In this model the View is able to request updates from the model. However due to the request/respond nature of the internet an action generally needs to occur such as the user clicking a button to start the cycle, the view is not able to request updates directly from the model. In the MVC architecture for the web as shown in Figure 2, requests are routed to the corresponding controller class, which processes the request.

Figure 2: The MVC Architecture for the Web (Sanderson, 2009)

Design Patterns

Observer

The observer pattern (See Figure 3) enables one object known as the observer to watch another object known as the subject. The observer pattern allows observers to register with a subject, when an event occurs for example an integer value changing state; the change is propagated to all registered observers (Sintes, 2001).

Figure 3: Observer Pattern (Freeman et al., 2004)

Composite

The composite pattern creates a hierarchical structure where the child nodes of the structure can be treated in the same way as their parent nodes.

In MVC the view is likely to consist of a window, which may contain a panel, which will also contain many other components. When the controller tells the view to update, by using the composite pattern it only needs to inform the top view component, and the composite pattern will allow the components contained within the top component to update themselves (Freeman et al., 2004).

Strategy

The strategy design pattern (see Figure 4) extracts code which handles specific tasks from the application (Holzner, 2006). For example in the case of MVC the view should only be concerned with the visual aspects of an application, such as rendering hyperlinks, buttons, or images. When an event occurs on the view the responsibility of handling that event is delegated to the controller. The strategy pattern provides the un-coupling of the model from the view as the controller interacts with the model. The view has no knowledge of how the controller has handled the event, or how it has interacted with the model (Freeman et al., 2004).

Figure 4: Strategy Pattern (Freeman et al., 2004)

Repository

The goal of the repository pattern is to uncouple the model from the underlying database technology. This is achieved by isolating the applications data access logic from the rest of the application. By using the repository pattern it allows the application to implement different database technology in the future (Walther, 2010). For example perhaps the systems database is no longer supported by the database vendor and it becomes critical to swap database vendors, by implementing the repository pattern this can be achieved easily without breaking other parts of the system. Whereas if the data access logic is tangled in the core of the application it may require significant refactoring to convert database access calls to the new vendor’s protocol.

Works Cited

Anon., 2007. Model View Controller. [Online] Available at: http://www.phpwact.org/pattern/model_view_controller [Accessed 26 February 2010].

Burbeck, S., 1992. Application Programming in Smalltalk-80(TM): How to use Model-View-Controller(MVC). [Online] Available at: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html [Accessed 26 February 2009].

Freeman, E.T., Robson, E., Bates, B. & Sierra, K., 2004. Head First Design Patterns. 1st ed. O’Reilly Media.

Holzner, S., 2006. Design Patterns for Dummies. Hoboken, New Jersey, United States of America: Wiley.

Sanderson, S., 2009. Pro ASP.NET MVC Framework. New York, United States: Springer-verlag.

Sintes, T., 2001. Speaking on the Observer pattern. [Online] Available at: http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html [Accessed 26 February 2010].

Walther, S., 2010. Sams ASP.NET MVC Framework Unleashed. United States of America: Sams Publishing.