mykimchi.NET Blog

What is MVC?

MVC - Model-View-Controller - is a design pattern for the architecture of web applications. It is a widely adopted pattern, across many languages and implementation frameworks, whose purpose is to achieve a clean separation between three components of most any web application:

* Model: business logic & processing
* View: user interface (UI)
* Controller: navigation & input

What are the benefits of MVC?

MVC benefits fall into multiple categories:

* Separation of concerns in the codebase
* Developer specialization and focus
* Parallel development by separate teams

In looking at these in a little more detail, it will become clear that the second two bullet-points are corollaries of the first.

Separation of concerns

Separation of Model, View, and Controller:

* allows re-use of business-logic across applications
* allows development of multiple UIs without touching business logic codebase
* discourages “cut-&-paste” repetition of code, streamlining upgrade & maintenance tasks

Looking at the other side of the same coin, intermingling M, V, and C code makes for:

* bigger, knarlier, harder-to-maintain classes
* repetition of code in multiple classes (upgrade & maintenance issues)

Developer specialization and focus

* UI developers can focus exclusively on UI, without getting bogged down in business logic rules or code
* Business logic developers can focus on business logic implementation and changes, without having to slog through a sea of UI widgets

Parallel Development by Separate Teams
* Business logic developers can build “stub” classes that allow UI developers to forge ahead before business logic is fully implemented.
* UI can be reworked as much as the customer requires without slowing down the development of code that implements business rules.
* Business rule changes are less likely to require revision of the UI (because rule changes don’t always affect structure of data the user sees) .

Templating

In order to maintain a consistent look-and-feel on a site, pages are often templated.

The web page’s is where core business content of a page can be found. Using a template to render a consistent header, footer, and navigation UI around the core business content standardizes a site’s graphic presence, which tends very strongly toward making users’ experience smoother and less prone to error.

Styling Web Pages with CSS

Cascading Style Sheets are a critical component of rendering a consistent look and feel in a web site (cf. this CSS Tutorial for more on Cascading Style Sheets).

CSS is used to specify colors, backgrounds, fonts and font-size, block-element alignment, borders, margins, list-item markers, etc. By specifying the designer’s choices in a single file (or group of files), and simply referring to the style sheet(s) in each web page, changes in style can be accomplished without altering the pages themselves.

Skinning (or Decorating) a Web Page using Sitemesh

Templating and styling are aspects of an important “Gang of Four” design pattern, called the Decorator Pattern. Using the Decorator Pattern simply means wrapping some core object in something that gives it additional functionality. In the context of building a user interface for the web - the View layer of an MVC-architected application - this might mean wrapping:

* core business information in a
* template (e.g., header + footer + navigation), which includes (in the common HTML header) reference to a
* CSS stylesheet (where background, colors, fonts, etc. are specified)

In order to implement this design pattern in the view layer, page decorating frameworks, such as OpenSymphony’s SiteMesh can simplify the process. SiteMesh intercepts HTML pages produced statically and/or dynamically, and applies a uniform “skin” to them, as specified in configuration files.

Responsibilities of the Controller

The Controller will do the following:

* Parse a user request (i.e., “read” it)
* Validate the user request (i.e., assure it conforms to application’s requirements)
* Determine what the user is trying to do (based on URL, request parameters, and/or form elements)
* Obtain data from the Model (if necessary) to include in response to user
* Select the next View the client should see

The sequencing of calls to the Model (business-logic layer), and/or the sequencing of views and required input from the user defines the application’s workflow. Workflow is thus defined in the Controller layer of the application.