Model-View-Controller pattern in a web application
I am not going to discuss or describe the Model-View-Controller (MVC) pattern itself - you can have a look at Martin Fowler's Patterns of Enterprise Application Architecture. Rather, I am going to look at how MVC within a web application relates to architectural layers.
Terence Par described MVC in web applications as follows:
- M represents an application’s data (including the persistence layer such as a database), all of the business logic, and any model-related computations.
- V represents a page's template or templates
- C represents both the server’s dispatch infrastructure that maps a URL to a code snippet and the code snippet itself
- the 'overlord' that maps incoming HTTP URL requests to a particular handler for that request
- the handlers themselves, which are often called "controllers." The controller also receives requests (including HTTP POSTs etc) and processes these, probably using the Model to do this. The controller then pushes the response into the views or templates.
Some of the benefits of using the MVC pattern are:
- allows separate specification and development of the business logic and the user interfaces. The domain model can be more cohesive, focusing on business processes
- separation allows for division of labour - designers can work on templates with minimal input from developers. A designer can change the tepmlates without requiring a programmer to update model code
- new views can be easily added without changing the domain model, and views are interchangeable
- to allow execution of domain model without the user interface. Separation allows you to build mock objects that mimic the behavior of concrete objects during testing.
MVC, layers, tiers
The MVC pattern is not the same as the layered architectural style (or tiered architecture), but it does support it's use. There is general consensus that layers and tiers are not quite the same. Briefly:
- layers are logical groupings of the functionality and components in an application. To put it another way a "layer is a very coarse-grained grouping of classes, packages, or subsystems that have cohesive responsibility for a major aspect of the system". Any number of layers of an application can be on the same processing node
- tiers describe the physical distribution of the functionality and components on separate servers, computers, networks, or remote locations i.e. tiers refer to actual physical separation of system components
A common architecture for web applications is the three-layer architecture consisting of presentation, business/domain logic, and data layer/data sources logic. An example representation from Microsoft Application Architecture Guide 2nd Edition (Patterns & Practices) is shown below:
The primary responsibilities of the layers are as follows:
|Presentation layer||Contains functionality responsible for managing user interaction with the system, and generally consists of components that provide a common bridge into the core business logic encapsulated in the business layer. [Martin Fowler] "The primary responsibilities of the presentation layer are to display information to the user and to interpret commands from the user into actions upon the domain and data source"|
|Business or domain layer||This implements the main functionality of the system which makes up the business logic - what it's all about. This includes all computations based on user input, validation, invoking data source objects|
|Data source layer||Provides communication with databases and other external data services. This layer exposes interfaces that the components in the business layer, and, to a lesser extent, the presentation layer can consume|
This then suggests that the view and controller in MVC are actually part of the presentation layer in the three layer architecture. The M in MVC corresponds to the other two layers.