The Model component of MVC deals with an application's data. This includes data that is displayed to the user, received from the user, and stored in the database. Additionally, the Model handles all Create, Read, Update, Delete (CRUD) operations with the database. Many frameworks also use the Model to handle an application's business logic, or how the data should be manipulated before being saved or viewed, but this is not necessarily a standard.

In the simplest terms, the Model in an MVC web application is a representation of the application's data. That data may include anything relevant to the application, such as the current user's information. Traditional web application frameworks use relational databases, such as MySQL, to store data. Modern SPA architectures, however, are now gravitating more and more toward document-oriented databases, or what is commonly referred to as NoSQL. MongoDB and many other NoSQL databases use JSON documents to store records. This is great for frontend architectures because JavaScript can directly parse JSON, and in the case of the MEAN stack, JSON data is native to every tier of the architecture.

Let's take a current web application's user information as an example. We will refer to this as the User Model :

{ 
    "id": 1, 
    "name": { 
        "first": "Philip", 
        "last": "Klauzinski" 
    }, 
    "title": "Sr. UI Engineer", 
    "website": "http://webtopian.com" 
} 

A simple JSON document like this will be returned from the database to your app for direct parsing by JavaScript. There is no need for any Structured Query Language (SQL) with a document-oriented database, hence the term NoSQL.

The core component of MVC is the View, and it is likely the one you are most familiar with if you are a frontend developer. The View embodies everything that the user interacts with, and in the case of a web application, what the browser consumes. Traditional MVC frameworks serve Views from the server, but in the case of a JavaScript SPA and using an architecture like the MEAN stack, the View is contained entirely in the frontend. From a development and asset management standpoint, this makes things a lot easier to maintain because the dual aspect of dealing with Views both on the server side and the frontend does not exist.

The templates for Views in a JavaScript SPA are written using HTML mixed with some type of web template system such as Underscore, Handlebars, or Jade, as only a few examples. A web template system allows your HTML markup to be parsed by JavaScript and evaluated for expressions that place dynamic data and content within your Views. For example, let's look at a simple Handlebars template using the User Model from earlier:

<h1>User Information</h1> 
<dl> 
    <dt>Name</dt> 
    <dd>{{name.first}} {{name.last}}</dd> 
    <dt>Title</dt> 
    <dd>{{title}}</dd> 
    <dt>Website</dt> 
    <dd>{{website}}</dd> 
</dl> 

Imagine an AJAX request is made for the currently logged-in user's data, and the SPA returns the User Model JSON document from a GET request. The properties from that JSON document can be directly inserted into the View for that request. In the case of Handlebars, a set of two opening and closing curly braces ({{ ... }}), or double curly brace notation, is used to identify expressions to be parsed within the template. In this case, those expressions are simply the user's first name, last name, and title. For more information on Handlebars templates, see handlebarsjs.com.

The Controller component in the MVC pattern is the most variable between different frameworks, and thus the most difficult to define with true clarity as a general concept. In a traditional web application MVC framework such as Ruby on Rails or CakePHP, the Controller takes input from the user in the form of web requests, or actions, and makes changes to the Model before rendering a new response in the View. The following diagram shows the flow of the Controller within the MVC paradigm:

(Diagram from Wikipedia - https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller#Components)

With this representation of the Controller, it is easy to see how it could encapsulate a great deal of application code, and in fact when working with some MVC web frameworks, it is often difficult to know where to draw the line between Controller logic, business rules for the Model, validation rules for the View, and many other common components of a web application. This nebulous nature of the Controller has led to the decision of the authors of many modern web frameworks to move away from the term Controller entirely and adapt a new concept in its place.

The Model and the View components of MVC are easy to understand and to differentiate  their purposes within a web application, but the Controller is not so clear-cut. Let's now explore some of the concepts that have replaced the Controller in more recent web application architectural patterns.