How MVC framework works (basics)
Coding (PHP 8)
The Model-View-Controller (MVC) framework is an architectural pattern that splits applications into three main parts, read to learn how it works
Can you name me another place that looks like a church?
As a kid, coming from a religious country, I often happened to spend a few hours a week inside this type of building.
I am sure you have been in one or two as well.
Think for a moment at the amazement when entering a structure so grandiose.
The tall walls, and the decorated roofs, and remember how large the naves were?
A particular aspect of churches is their structure.
They all look similar and their shapes are there because of a reason.
I am sure that you haven’t stopped and focused on the framework that has been used to make them.
Yet it is there.
As per a building, even your favorite coding project should have a good structure.
In recent years these structures have been proposed by PHP frameworks.
Many of them use a pattern called Model-View-Controller.
This architecture sounds confusing to many developers approaching it for the first time.
No worries.
In this post, I’ll show you what MVC architecture is, and how to use it.
Let’s jump into it.
What MVC is not?
Let’s start with what MVC is not.
MVC stands for model-view-controller and it is not a framework.
Model-View-Controller is an architectural paradigm.
What?
Think of it as the structure of your project.
It can be considered a way of thinking,
A method for structuring your website
Why it is so popular?
The MVC pattern is an architectural style that follows the SOLID principle,
and is used by many frameworks.
Laravel, CakePHP, Symfony, and many other PHP frameworks use it.
I wrote an introduction about Symfony 6 here.
All these frameworks use the MVC structure.
It means that to use these you actually need to understand what MVC is.
What is MVC?
MVC is a structure, like a blueprint.
It is divided into 3 parts
- M (model)
- V (view)
- C (controller)
MVC creates the structure that the programmer needs to use on his/her project.
This allows you to be DRY and write better code.
The Flow of a website
Let’s analyze for a minute how a website work.
Client Pt.1
The client is where you as a user view the internet.
What you see from a web browser is generally a mix of HTML, CSS, and Javascript.
The client's job is to look nice and send requests to the server when you need some information from the server.
Server Pt.1
A server is a machine that runs on Linux or Windows and works on server-side languages.
Those can be PHP, Ruby, Python, Go, etc.
This part of the system understands what information you need.
It also queries the database to retrieve it.
Servers do not store any information.
What they do is validate the data, being sure that the user is not doing anything malicious.
Also protecting the database by preparing queries.
These queries’ purpose is to get data from the database
Database
This is the last element of the flow.
The database is where the data is kept.
There are different types of databases.
The most popular are MySQL, MongoDB, and PostgreSQL.
This contains all the storage.
They can be relational or non-relational.
But it does not matter what type of database you want to use as an MVC framework will work anyway.
The database retrieves the data you are looking for and returns it back to the server.
Server Pt.2
Once the information from the database hits the server, the server then can process it.
Here is where we format data, paginations added, and other processes.
Anything that needs to be done before you can see the results on the client again.
Once all this info is ready, then the server sends them back to the client.
Client Pt.2
Now the client has the information that you want.
What it does is display it.
Arrange them as a list, add some nice designs, and show them to you.
The Flow of an MVC project
Now that you understood how a website work it will be very easy for you to get what MVC means.
Some smart people analyzed the process described above
and decided that it would be a great idea to replicate it in the code’s structure.
As the flow is made by 3 different sections an MVC architecture is formed by 3 parts too.
Where the database is represented by the Model
The server symbolizes the Controller
and the View represents the client.
The Model
The model does a few things.
Add and retrieve records from the DB.
also, it Processes data from the database via repository, relationship, etc.
A model is only connected to the controller.
The model never EVER speaks to the view directly.
The View
A view consists of all the shapes and info you, as a user, see on a web page.
these ‘shapes’ are made of HTML and CSS.
the view only talks to the controller.
to be precise, it only listens to the controller.
It retrieves the data the controller sends and shows it to you on a web browser.
The Controller
The controller is what is interacting with the user.
As a backend developer, this is where you will need to spend most of your time.
This section process all the requests incoming using server-side logic.
Think of the controller as a middleman between the views and the models.
It takes information from the view, process all the info necessary, and talk to the DB.
A database request is not always required.
Then receive the information from the database.
After a bit of clean-up, send it to the presentation layer (the view).
More features of an MVC framework
Now you know the basics of how the MVC pattern works.
Also, you understood that MVC frameworks follow this pattern.
To make a framework work properly other parts are implemented in the code.
To learn more read the Q&A about PHP frameworks
These parts can be inside or work alongside the 3 main sections.
For example,
one important part that stands between the view and the controller is the Routing system.
Routing system
The Router lives between the views and the controllers.
Given a project can have much functionality it is good to have different flows for each of them.
That means having different views, controllers, and different models.
If you want to search the content of a website there will be a SearchController.
In case you want to add a comment to a post, you might need a PostController.
and so on.
To point the code to the right controller we need to follow a specific route.
Route processors are the part that is in charge of it.
Template engine
A template engine lives within the view.
When HTML is not powerful enough for what you want to do is time to add some power to the front end.
Any of the bigger MVC frameworks have their own template engine.
For instance, Symfony has Twig, Laravel has Blade, etc.
They allow do to things like the following on the view page.
{% if user.isLoggedIn %} Hello {{ user.name }}! {% endif %}
ORM
Object Relational Mapping (ORM) is another very important part of many MVC frameworks.
Using an ORM means creating a link between the code (in most cases OOP code) and a database.
Query languages are not the easiest ones to deal with,
especially when you want to create fast and secure applications.
ORM helps you communicate with the database and receive data in the format you prefer.
Services, Transformers, Commands, Repositories, etc
S.O.L.I.D. is a big thing in the engineering world.
and there is a reason for that.
Code that follows these rules is easier to read, and update and has fewer bugs on it.
Having 3 sections taking care of complex systems is not ideal and it can become cumbersome.
A solution for it is to split this architecture into more layers.
You can add a services class to the controllers to make them leaner.
Or set repositories class in charge of SQL queries while models only take care of the entity.
MVC frameworks are just that, frameworks.
You should be able to take advantage of their helpers but learn to edit them as your code need them when needed to.
If you want to start with a PHP framework now, I created an article describing how to install Symfony 6 and start to create a web app locally.
Conclusion
I remember when I first heard about MVC it was difficult for me to grasp what this meant.
I did not have any experience using a framework.
In the beginning, these words were very difficult to understand.
I later found out that the real difficulty lay in understanding the abstract concept.
In fact, the concrete implementation was quite straightforward.
Think of dividing the code into different parts depending on what the section’s goal is.
If, after reading this post, you still have issues understanding the concept. subscribe to the newsletter and I’ll make sure to add more details in the following post.