Instructor: Up until this point,
we have just written our code without thinking much
about our application architecture.
It wasn't really important until now,
but now that our app is really starting to grow,
we need to start worrying
about the way that we design, or code architecture.
And this lecture will just be a brief introduction
to back-end architecture.
Starting with the MVC architecture.
So, in this project, we're going to use
a widely used and well known architecture
called the model, view, controller
or MVC for short.
And there are different ways
of implementing the MVC architecture,
some more complex than others,
but we're going to implement it
in a very straightforward way here.
I just wanted to let you know that
if you Google around for MVC,
you'll find it implemented in some different ways.
Okay, anyway, in this architecture,
the model layer is concerned
with everything about applications data,
and the business logic.
And we're going to learn what business logic means
in the next slide.
Next up, we have the controller layer
and the function of the controllers
is to handle the application's request,
interact with models,
and send back responses to the client.
And all that is called the application logic.
Finally, the view layer is necessary
if we have a graphical interface in our app.
Or in other words, if we're building
a server-side rendered website,
as we talked about before.
In this case, the view layer consists basically
of the templates used to generate the view,
so the website that we're going to send back to the client.
And that is the presentation logic.
For now, we're just building an API though,
so we're not really concerned about views just yet.
That's for a bit later in the course.
So using a pattern, or an architecture like this
allows us to write a more modular application,
which is going to be way easier to maintain in scale,
as necessary.
And we could take it even further,
and add more layers of abstraction here.
But in this kind of smaller application,
the MVC architecture is more than enough for our needs.
Now, all this may sound a bit abstract,
so let's take a look at MVC in the context of our app,
and the request-response cycle.
So as always, it all starts with a request.
That request will hit one of our routers,
because remember, we have multiple routers.
Basically, one for each resource,
like tours, users, et cetera.
Now the goal of the router is to delegate the request
to the correct handler function,
which will be in one of the controllers.
And again, there will be one controller
for each of our resources,
to keep these different parts of the app nicely separated.
Then, depending on the incoming request,
the controller might need to interact
with one of the models,
for example to retrieve
a certain document from the database,
or to create a new one.
Once more, there is one model file for each resource.
After getting the data from the model,
the controller might then be ready to send back a response
to the client, for example, containing that data.
Now, in case we want to actually render a website,
there is one more step involved.
In this case, after getting the data from the model,
the controller will then select
one of the view templates and inject the data into it.
That rendered website will then be sent back
as the response.
In the view layer in an Express app
there is usually one view template for each page.
Like a tour overview page,
a tour detail page, or a login page.
In the example of our latest app of course.
So, that is a broad overview of the architecture
that we're going to implement in this project.
Now to finish, let me just go into
a bit more detail on model and controller.
So, one of the big goals of MVC
is to separate business logic
from application logic.
You'll hear about these types of logic all the time
when you browse Stack Overflow,
or some site like that.
But what are these types of logic actually?
Well, the difference is a bit opinionated,
but this is my take on it:
So, application logic is all the code
that is only concerned about
the application's implementation
and not the underlying business problem
that we're actually trying to solve with the application.
Like showing and selling tours,
managing stock in a supermarket,
or organizing a library, for example.
So again, application logic
is the logic that makes the app actually work.
For example, a big part of application logic in Express,
is all about managing requests and responses.
So, in a sense, we can also say
that application logic is more about technical stuff.
Also, if we have views in our app,
the application logic serves
as a bridge between model and view layers
So that we never mix business logic
with presentation logic.
All right?
Now, about business logic,
it's all the code that actually solves the business problem
that we set out to solve.
Let's say again, that our goal is to show tours to customers
and then sell them.
And the code that is directly related to the business rules,
to how the business works,
and the business needs, is business logic.
Now if that still sounds a bit too philosophical,
some examples in the context of our latest app
are creating new tours in the app's database,
checking if a user's password is correct when he logs in,
validating user input data,
or ensuring that only users who bought a certain tour
can review it.
So all this stuff is concerned with the business itself,
and so it's part of the business logic.
Now, we need to keep in mind that
application logic and business logic
are almost impossible to completely separate,
and so sometimes they will overlap.
But we should do our best efforts
to keep the application logic in our controllers
and business logic in our models.
And there is even this philosophy of
fat models, thin controllers,
which says we should offload
as much logic as possible into the models,
to keep the controllers as simple and lean as possible.
So a fat model will have as much business logic
as we can offload to it,
and a thin controller will have as little logic as possible,
so that the controller is
really mostly for managing the application's requests
and responses.
Okay?
So, now keep all this in mind as we move on
and progress into building our applications.