Lesson 1 - Introduction to the MVC architecture in ASP.NET Core
In the previous lesson, , 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).
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.
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.
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
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.
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:
Profile.cshtml and so on. However, the
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
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.
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
ArticleController and so
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:
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.
No one has commented yet - be the first!