TL;DR:
MVC = Model View Controller. Data from a database is represented as a model class. The view takes that data represented by the model and inserts it into an HTML template that is written into the view. The controller is responsible for creating the model from data retrieved from a database and passing that model into the view.
It’s an Architectural Pattern:
MVC stands for Model View Controller. It is an architectural pattern that many other frameworks use, not just ASP.NET. Spring MVC, Node.js MVC frameworks, and Ruby On Rails MVC frameworks are just a few of the other languages that support the MVC pattern. However, my experience is primarily with ASP.NET so this post will be based on ASP.NET MVC but it should apply to most other MVC frameworks.
The primary goal of MVC is something called Separation of Concerns. I’ll cover that in more detail later on, but in a nutshell, SOC is the idea that a unit should do one thing, only one thing, and do it as efficiently as possible. MVC accomplishes this by delegating important functions of web applications into three separate concerns.
The Model:
The Model is just a class (at least in ASP.NET) that typically represents an item in a database table. It contains variables that directly correspond to the schema of that table.
This is what the Products table in a project I’m working on looks like:
This is what the C# model that represents that table looks like:
public class Product
{
public int ID { get; set; }
public int BrandID { get; set; }
public int ModelID { get; set; }
public string InfoPage1 { get; set; }
public string Notes { get; set; }
}
The View:
The View is a file that contains a display layout. They are designed to stand alone as a full page, or they can act as partial pages. Think of them as a template for displaying information to the user. In the case of a partial view, you can have as many partial views as you need in a single parent view (Yes, they are nest-able). When a view is created, if it requires table data (hint: they don’t always have to have data!), the data is passed into it and can be used to modify the view to represent that particular table row (aka Model).
My view for my product model looks like this:
@model IEnumerable<InventoryManagementSystem.Models.Product>
<table class="table">
@foreach (var item in Model) {
<tr>
<td>
@Html.DisplayFor(modelItem => item.BrandID)
</td>
<td>
@Html.DisplayFor(modelItem => item.ModelID)
</td>
<td>
@Html.DisplayFor(modelItem => item.InfoPage1)
</td>
<td>
@Html.DisplayFor(modelItem => item.Notes)
</td>
</tr>
}
</table>
This view incorporates something called Razor syntax to hold the model and pull out the necessary information. It uses standard HTML to create the rest of the template. This view simply looks through a list of models and prints them all out into an HTML table.
The Controller:
The Controller is the magic that puts it all together. You might even say it *ahem* controls the application. What I mean by that is when a user initiates some kind of event on your web app such as clicking a navigation link or submitting a form, the controller is responsible for actually handling that event.
When clicking a link, we expect to go to a different page. A method in the controller is called that returns the view designated for that page and sends it back to the user. These methods are referred to as actions. In the case of a form submit, let’s assume we’re changing the name of someone in a database. When the user presses submit, an action is called in the controller that takes that form data in the form of a model and makes the necessary changes to the database table based on that model. It can either return a new view at this point or just return some kind of status message back to the user.
This is what one of my controller actions looks like for the Product model and view:
public ActionResult ListProducts()
{
var products = db.Products.ToList();
return PartialView(products);
}
db.Products.ToList() goes to the database, finds all of the items in the Products table and returns them as a list of product models. Next, it returns a partial view that accepts that list as a parameter. This is where the view gets it’s data to plug into the template.
Let’s look at a chart:
Hopefully you now have a better understanding of MVC. Lastly, I want to add this a flow chart that shows how all of this looks in practice:
User Action: Let’s say the user clicks on a link to take him to the page that lists all of the products in our database.
Step 1: The page tells the controller to perform the action that returns the Product Detail View.
Step 2: The controller might do some logic first but ultimately, it goes to the database, retrieves the appropriate data.
Step 3: The controller creates an instance of the Product model class, and since we are wanting ALL of the products in the database, it will create an instance for every product that it found in the database.
Step 4: The controller passes all of the model instances into the view which incorporates the model data into the HTML that is returned to the controller.
Step 5: The controller sends that view back to the user to display the new page.
That’s MVC
Hope you guys enjoyed reading this. If you’ve got anything to add or need clarification, or just want to tell me I screwed something up, let me know in the comments or over at the forums!
