The MVC paradigm divides the logic of a web application into three distinct areas, or concerns: model, view, and controller. In practice, each concern comprises multiple components and files. A typical MVC application contains a number of model classes, view templates, and controller classes.

Here's how the separate concerns work:

Model

Applies logic to data. Essentially, the model handles the business logic of the application and any other logic not contained in the view or controller. Model objects represent and manipulate data. In the CMS environment, the model is built on XML data.

View

Displays data pulled from the model. The view layer renders a user interface for the application. Using markup and code, a view template generates an HTML page to be served to a client.

Controller

Handles input logic for the application. The controller passes queries from the user to the model, and controller methods call views in response to user input.

In websites built with traditional ASP.NET technology, a single URL corresponds to a single web page. In an MVC application, this is not the case. A URL corresponds to a controller action. Each browser request is mapped to a controller action, and these mappings are defined by a routing table in the Global.asax file.

For example, in the DSS sample solution, the Index() action on CMSPageDefaultController channels all browser requests for CMS pages.

public virtual ActionResult Index()
{
    return handleRequest(handleNoneCmsPageRoute,
    handleCmsPageRequestWithRemainingPath,
    handleStandardCMSPageRequest);
}      

The Index() action returns different results, depending on the type of request. For instance, if the routing request doesn't point to a CMS page, handleNoneCmsPageRoute is called, and, by default, introduces a 404 error. The default controller also handles standard page requests and requests involving a path that doesn't fully resolve.