Now, in the last lecture,
I mentioned that all these database operations
in these route files are another aspect
that could probably be refactored or outsourced
to reduce the amount of code in those route files
and put that code somewhere else.
And for that, we got a specific pattern,
which is very common.
And which we can use here as well.
As everything, it's not a must use pattern,
but it is, as I just said, a very common pattern.
And you will see it in a lot of web projects, though,
not just there.
Instead, it's a general programming pattern,
which you will often see if you're building applications
or websites that have user-facing parts.
So things that can be seen by the user.
And then a lot of backend logic parts you could say.
And that's the MVC pattern,
which stands for model view controller.
Now, what are these things
and how do we apply this pattern to our code base?
The idea is that you split your main code
that is involved in handling incoming requests
and sending back responses into these three main areas.
The model area is about all the logic
that's related to working with your data source,
your database, for example.
So all the logic that is involved there.
So for example, storing blog posts,
fetching blog posts, and so on.
That all should typically go into your model files.
And of course, you will see how we can create
such model files throughout this section.
Now, here, you would therefore defined functions
or methods for storing data in databases
or fetching data from a database.
Though, the model concept really applies
no matter which data source you might be using.
If you are working with file storage,
you could also implement that with that MVC pattern.
Now, the view part is the part we already are using.
We have our templates.
And the templates are the building blocks
that contain the logic for presenting
the data or the content to the user.
So we're already doing that.
And in those templates, we are of course,
using the EJS templating language with all its tags
that it's offering to us to output repeated content
or conditional content.
And therefore, that logic already is in the right place.
In case you're wondering where else it should be stored.
Keep in mind that when we got started
with diving into backend development,
we started by defining the HTML code that should be returned
directly in our request handler functions.
We didn't use templates right from the start.
And there for example,
we therefore didn't have that separate view logic
or that separate view part.
Instead, we had everything in our JavaScript code
and everything in the same file.
So we're using this view logic already,
but we didn't use it right from the start.
And using it as we're currently doing it is recommended,
especially when using the MVC pattern, but not only then.
Instead, views should always have separate template files.
Now, the last part is the controller.
And that's in the end a code that contains
the logic for connecting your models to your views.
So that is the part where you work with your models
to tell them to fetch data, for example.
And where you then pass that fetched data into your views.
And therefore, controllers are typically the functions
that are executed when your routes trigger.
So you could say that the code
in your route files is your controller code.
Though, at the moment, since we're not using models at all,
we don't have correct controllers in our website
because we're doing way too much work
in those controllers at the moment.
And therefore, that's the MVC pattern.
And we're not using it yet.
We're only using the view part.
Therefore, in the next lectures, we're going to apply
the MVC pattern on the website code we have here.
And you will learn step by step
how you implement it so that you can implement
it in any website project you might be working on.