Lesson 3 - Introduction to the MVC architecture in ASP.NET Core

In the previous lesson, Introduction to ASP.NET web applications, we explained why it's a good idea to program our application as a web app. If you read this tutorial, you have decided to learn the ASP.NET Core MVC technology.

Although there are more ways to create an application in ASP.NET Core, we'll start with the most popular - MVC. This is a very famous architectural pattern, which has become popular especially on the web, although it originated on desktops. It's part of well-known web frameworks, such as, besides ASP.NET Core MVC, e.g. Zend or Symfony for PHP, and Ruby On Rails for Ruby. Personally, I can't imagine a more complex website without it (or any similar principle).

Motivation

The core idea of the MVC architecture is separating the logic from the output. It solves the problem of so-called "spaghetti code" when there are logical operations mixed with output rendering in a single file (class). So the file contains database queries, logic (C# code), and HTML fragments. Everything is tangled together like spaghetti.

Of course, such code is hard to maintain, even harder to extend. It's badly highlighted because the IDE doesn't know how to handle it. HTML isn't formatted properly, we're lost in its tree structure. Our goal is to make the source code with logic look like regular C# source code, and the output like an HTML page with the smallest amount of any additional code.

Components

The whole application is divided into 3 types of components, we talk about Models, Views, and Controllers, abbreviated as MVC. There's no strict definition of the architecture, so you can find multiple interpretations. We'll focus on the most common one.

Let's describe each component first.

Model

Models contain logic and everything that falls into it. These can be calculations, database queries, validations, and so on. For us, it means that the models are regular C# classes, as we've known them so far. Models don't know about the output at all. Their purpose is accepting parameters from the outside and returning data back. Let's emphasize that by the parameters we don't mean the URL address or any other parameters from the user, but the parameters of the model class methods. Models don't know where the data came from and how the output data will be formatted and printed.

In the course, we'll use Entity Framework, our models then match the database tables. So we have the User, Comment or Article models. Model instances, of course, contain properties from the database. E.g. an instance of the User model has the Name property. We can define instance methods in the model class, e.g. one that calculates the age of the user by their birthday.

Now we have an idea of ​​what models are doing, let's take a look at views.

View

Views take care of displaying the output to the user. They're HTML templates, containing an HTML page and special language tags that allow us to insert variables into the template or eventually, iterate through items (loops) and conditions. Therefore, the User.cshtml view will print user details, the Article.cshtml view will print the content of the article.

We have many views, for example, for the user entity features: Registration.cshtml, Login.cshtml, Profile.cshtml and so on. However, the Profile.cshtml view is common to all the users and different data are sent to it, depending on who we're currently looking at. Those data are then pasted into the HTML template elements.

Of course, we can nest templates to avoid repeating ourselves (the page layout template, the menu template, and the article template).

A view isn't just a template, but an output viewer. It contains the minimum amount of logic that is necessary to display the output (e.g. checking whether the user has filled their nickname before printing it or looping through the comments while printing them).

Views, like models, don't know where the data came from, they only take care of displaying it to the user.

Controller

Controllers are now the missing element that will clarify the functionality of the whole pattern. They're mediators that the user, model, and view communicate with. They keep the whole system together, and connects the components. We'll understand their role from the example of the page life cycle. Most often, each entity has one controller, so we have UserController, ArticleController and so on.

The webpage life cycle

The life cycle is started by the user who enters the website address and parameters into the browser to tell us which page they want to display. We'll want to see the details of the user with the id 15. Let's make an example of the URL address:

http://www.domain.com/User/Detail/15

The request is captured by the router first. It determines which controller to call based on the parameters.

The given controller determines by the other parameters what is requested, in this case it has to display the details of the user. It calls the model that looks for the user in the database and returns their data. It also calls another method of the model, which, for example, calculates the age of the user. The controller stores these data in variables. Finally, it renders the view. We can determine the view name by the action we're performing. Variables with the appropriate data are passed to the view. So the controller listened to the user, obtained data from the model according to the query parameters and passed it to the view.

The view receives the data from the controller and pastes it into the template. The finished page is displayed to the user who often doesn't even know about this beauty

We can illustrate the whole situation with a diagram:

So we've separated the logic from the output, the views are in HTML, the models are in C#. Our code is readable and divided logically.

When developing a project, MVC architecture even makes thinking easier for us. When I write logic, it belongs to the model, formatting and styling the output should be in a template. I determine what the user wants from the parameters in a controller. 3 different issues in 3 different places, separated so that they don't interfere with each other and don't make our development more complicated.

ASP.NET MVC vs. ASP.NET Core

ASP.NET (as well as the entire original .NET framework) is managed by the Microsoft corporation and has been targeted to the Windows operating system only for a long time. However, since we often need our website to run on another OS without any extra work (for example due to the webhosting), this restriction has been quite limiting for developing in .NET. Moreover, other disadvantages have come by compared to other languages, e.g. that .NET isn't open source.

That's why a few years ago Microsoft decided to revive and rewrite the framework. The result is the new high-level .NET Core framework. It's now multiplatform, open source, and brings several other benefits, such as the built-in DI (Dependency Injection), better performance than the original ASP.NET, or the ability to have multiple versions of the framework on one machine at a time. Core has also been rewritten to use more modern architecture.

The current main disadvantage of Core is that, although it has much in common with the older .NET and supports all of the .NET standard components, we still wouldn't find some things from .NET in the .NET Core (and vice versa). So if you plan to just extend an existing, older application, it makes more sense to learn the original ASP.NET MVC, which is a bit more comprehensive after years of development. Not all third-party packages/libraries are available for Core.

At the moment, both technologies coexist and are being developed, both will be supported for some time, but there's no reason why we shouldn't work with the newer ASP.NET Core in our tutorial. In the next lesson, First web application in ASP.NET Core MVC, we'll create our first web application in the ASP.NET Core MVC.