The MVC Process Flow
Let's look at how we'll apply the MVC design pattern in three steps:
From concept to data model.
From data model to controller.
From controller to view.
Step 1: From Concept to Data Model
Whenever you build a new .NET MVC application, as with any other application, you begin with a concept and list of requirements. MVC apps are also typically data-driven. That means the app is designed to work with a specific type or set of data. Therefore, the first part of the app you design will always be the data model.
We have a pretty good idea of what we want to build, so we need to translate our conceptual idea to a data model that the app can use.
For Watchlist, you want an application that will allow you to enter movie titles and other pertinent information along with a personal rating, and store it for later viewing. You also want to be able to see a list of movies you have rated. Maybe they should be sorted by rating or date watched. You should also be able to view only movies you have not yet rated. You don’t want this app to become too complex, so let’s leave viewing requirements at the list stage. You won’t build a separate page to view full details about a movie (We’re not IMDB!).
Identify the Data Entities (Objects)
Let’s begin with the obvious: What are the main entities in the conceptual design? You could feasibly say there are four:
User - There are multiple users in our system.
Watchlist - Every user has one watchlist.
Movie - Every watchlist has multiple movies.
Rating - Every movie in a watchlist has one rating.
If this app was only going to be used by one person, then the rating could be a simple attribute of the movie object. Since the app has individual user logins, the watchlist then belongs to the user, and you need to add ratings for movies on a per-user, per-movie basis. So how would you define the relationships between these entities? Here are my suggestions:
Each user has a single watchlist.
Each watchlist has multiple movies.
Multiple users can rate the same movie, so the rating has to be linked to both the user and movie.
Here’s a rough diagram of the model so far (this is by no means complete):
Ok, you have an idea of what the model might look like, but you also know it’s not refined or even complete at this point. But we need to talk about how the model relates to a controller now, so we’ll come back to the model in the next chapter.
Step 2: From Data Model to Controller
Controllers in MVC are the action areas. They represent and handle the actual incoming HTTP requests and outgoing responses. I’ve mentioned the domain/controller/action route pattern that MVC follows. The controller portion of the route (or URL) is the name of the controller, and the action is the name of the method within the controller that creates the view the user wants to see. This means there is a direct, one-to-one relationship between a model and a controller.
Consider your movie entity. If you build a controller to work with your movie objects, it will likely be called MoviesController. All of the data handled within that controller will be related to the movie object. The controller will allow you to add, edit, delete, and list movies from the database by generating a view (HTML page) that corresponds to the HTTP request.
After you complete the final version of the data model, you will scaffold controllers and views for each of the C# classes that comprise the model.
Step 3: From Controller to View
The view is invoked by the return statement in the controller action:
return View();
This statement calls the View method from .NET MVC. This method looks for a view file in the Views folder of the current project that matches the current action and controller by name. It loads the appropriate layout file for the view, then reads the view file and executes whatever Razor code it finds while rendering the raw HTML, building a dynamic HTML file from the results, which it then returns to the requesting browser in response to the original request.
Our views will be built for us using generic templates by the scaffolding process, but they will need customization and refinement before they can be used effectively.
The Joy of Layouts
I’ve mentioned it before, but let me say it again: layouts in .NET MVC are fantastic!
Layouts let you break up HTML pages into reusable chunks. All of the common elements - those things that appear on multiple pages, such as menus, navigation bars, headers, footers, chat windows, etc. - can be placed in a layout file, while the elements that are exclusive to an individual page comprise the specific View file. The two are then merged in response to an HTTP request and delivered as a single dynamic HTML file.
In a .NET MVC project, you can create as many custom layouts as you need and assign them to specific views. You can even change the layout based upon the user requesting the page. This can be done by user role, or even individual user if you need to be that granular.
Later in the course, I’ll show you how to make the most of your layouts and speed up your .NET MVC development. But before we do that, let’s get back to this model. We need to complete it before we can do anything with controllers, views, or layouts.
Let's Recap!
In this chapter, you designed a preliminary data model based on the conceptual idea of the Watchlist application.
We identified possible entities you might need to create to form the model, and we talked about how to create MVC controllers to manage those entities.
We also talked about the direct, one-to-one relationship between controllers and models, as well as the relationship between controller actions (C# methods) and MVC views (.cshtml pages).
Finally, we talked about the importance of using layouts in .NET applications to simplify development and future maintenance of views.
In the next chapter, we’re going to further refine and complete the model, and then start coding it.
