In my opinion, this is one of the most exciting chapters in the book because, after all, this book is all about ASP.Net Core. And, in this chapter we are going to start learning our first ASP.Net Core framework; MVC.
We already talked about some of the problems of building a website by hand in straight HTML in Chapter 2, Module 1: Introduction to ASP.Net Core.
In this chapter we are going to learn how to solve these problems by rebuilding the Fred’s Cars local dealership landing and detail pages as a dynamic website using ASP.Net Core MVC as our dynamic framework.
MVC Architecture
We also already touched lightly on the MVC architecture in Chapter 2, Module 3: What is ASP.Net. Let’s quickly review the three MVC components and their responsibilities.
MVC Architecture
MODEL
Contains the business rules and provides access to the database for the controller.
CONTROLLER
Controls application flow. Receives the incoming URL request and sends CRUD (Create, Retrieve, Update, and Delete) requests to the Model, and provides the View with a Model of data to display.
VIEW
Responsible for rendering the data model sent from the controller in HTML to the user.
These definitions will become more clear once we start to model out our business domain and build some actual controllers and views.
Separation of Concerns
However, for now, just understand that using the above three components allows us to achieve separation of concerns. Dividing up the responsibilities of a web application between these three tiers makes each piece easier to focus on when we need to write or maintain code in that area of the application. It also makes the application easier to scale and test.
I don’t want to get too much into theory here. The best way to learn about each of the MVC components is to jump in and get our hands dirty. But let’s expand slightly on the definition of MVC and each of its components before we move on.
What is MVC
Microsoft gives the following definition for MVC.
ASP.NET Core MVC is a rich framework for building web apps and APIs using the Model-View-Controller design pattern.
In the above definition web apps refers to the kind of application we are going to build in this chapter; Fred’s Cars. APIs refers to another kind of application MVC can be used to build called Web APIs, or Web Services, or Rest Services. We won’t build any APIs is in this chapter. But, we will build out a pretty sophisticated Web API using MVC in Chapter 7, Intro to Full Stack Development where I also get into describing the MVC components more in depth for both Web Applications and API Applications.
Controller Responsibilities
The controller is responsible for working with the Model to perform user actions and/or retrieve results of queries. The controller chooses which View component to display to the user. And provides it with any Model data it requires.
Controllers should not contain any HTML. The controller is only responsible for application flow.
Model Responsibilities
The model represents the state of the application. It also contains the application’s business logic and operations. The model is responsible for persisting the state of the application usually to a database.
View Responsibilities
Views are responsible for presenting content. Typically the controller will pass data down to the view from the model and the view will render that data in HTML to the user.
The view should not contain any business logic or, at the most, very limited business logic. Business logic should live in the controller.
Testability
One of the biggest advantages to the MVC framework is the fact that it lends itself easily to testability. Because the application is broken up into three components, functionality is easer to isolate and test.
What’s Next
As promised I tried to keep the theory short in this module because I know you are excited as I am to get started building our project and writing some code.
In the next module we will create an ASP.Net Core MVC project using Visual Studio 2022.