In the previous lesson Lesson 3: First Laravel Application we created our first Laravel Application. In this lesson, we are going to learn in detail about How a Laravel application is structured. It is very, very important for you understand Laravel Application architecture, otherwise you will get confused about how things are working later. So, read and understand this lesson carefully.
1. Laravel is an MVC Framework
Laravel applications have a Model-View-Controller architecture. A Laravel application is divided into three interconnected components:
- Model – This part deals with application’s data. Model manages connectivity with database, storage and retrieval of data, and all the rules related to data.
- View – View is what the user sees. So, all our HTML code goes into the view.
- Controller – Controller does the connectivity between Model and View. When our application receives a request from a client, controller gets the parameters from request, gets the data from model and processes it. It then sends it to view and returns the generated view back to the client.
The diagram below will help understand exact flow of events:
If it’s a bit confusing, you can remember following equivalences:
Model = Data
Controller = Logic
View = Result
You apply logic to data and return the result with processed data.
2. Laravel Components
Laravel has a lot of components, many of which you will be coming across for the first time. Lets introduce you to all these components by following Laravel’s Directory Structure.
When you open myFirstApp‘s folder, you will see following directory structure:
Don’t panic if it looks bit complicated. You will get used to it in no time.
Let us get to know each folder’s purpose one by one:
1.1 app Folder
Majority of application code resides in this folder. It holds all our controllers, models, and other classes. It is divided into many sub-folders. Purpose of each folder and related Laravel construct is explained below:
a. Http – This folder holds the code of our application that directly needs to be used to serve web browser requests. An application can have loads of other things, like, background tasks and console commands which are not directly required to serve browser requests. They are kept in separate folders. This folder itself has 3 sub-directories:
i. Controller – This folder holds all the controller classes.
ii. Middleware – This folder holds all the Middleware classes. Middleware acts as a filter between browser request and controller. Using Middleware, we can perform certain checks on request before it reaches the controller. For example, we may want to ensure that a user is logged in before a request to update a blog post reaches the controller. We can very well put this check in controller itself, but it will cause a lot of code repetition and mixing of logic which can be easily avoided. So, we use Middleware in Laravel.
iii. Requests – Form requests are another way of filtering requests before they reach controller. Mostly these are used to validate submitted data. For example, checking if the email submitted is a valid email address and password is at least 6 characters long. Again, we can do this in controller itself, but its better to separate to reduce confusion in controller code.
b. Exceptions – This folder holds all our exception handler classes. When exceptions occur in our application, we may want to handle some exceptions differently. We can define exceptional handlers in this folder.
c. Console – In Laravel, we can define our own commands which can be run in terminal through php artisan interface. These commands are defined in this folder.
d. Events – Laravel allows us to register events that occur in our application. For example, user signup may be an event and we may want to send welcome email when that occurs. All the event classes are defined in this folder.
e. Listeners – This folder holds event handlers for events defined in Events folder.
f. Jobs – Many times we may want to run code in background to provide faster response to users. For example, we may want to send a welcome email when user signs up. However, sending email takes time because of network delay in connecting to SMTP server. So, we can queue this job to run in background and proceed with returning response to user. Such jobs are defined in this folder.
g. Policies – Policies are a convenient way to authorize user actions in a large application. For example, suppose we are creating a blog and we are adding a method to update a blog post. We will need to authorize only the user who created the blog post to update it. This can be done using policies. Policy classes are stores in this folder.
h. Providers – This folder holds all the application’s user defined service providers. In Laravel, service providers are a way of setting things up so that a package or particular part of your application can function properly. Setting things up can include registering event listeners, policies, routes and other things, configuring application, etc. You will not need to deal with Service Providers at basic level. So, just ignore them for now.
1.2 config Directory
As name suggests, it holds all the application’s configuration files. It has no fancy functions other than this.
1.3 database Directory
The database directory holds all the classes related to database. There are three types of classes corresponding to 3 directories in the folder:
a. migrations – Migrations are a way to make changes to database programatically. When we are working in a team, any change we make to database is difficult to propagate to other team members. If we add a column to users table, and there are 5 other team members working on same project, it will be very difficult and time consuming to make this change manually for each of them. Also, if the application is running live, it becomes difficult to manually make changes to database when we push updates. Migrations help us solve these issues. Whenever we make changes to database, we create a migration which contains code to make that change in database. Now, we can distribute the code to other team members and simply ask them to run the migrations.
b. seeds – Seeders are classes that insert dummy data to database so that we can test our application easily. For example, if we are creating a blog, we can insert thousands of blog posts, comments, users, etc. in one go using seeders.
c. factories – Factories are another way of feeding dummy data to database. Here we can define how to seed each field of a model. We can then create dummy models which in-turn create entries in database.
1.4 public Directory
1.5 resources Directory
Resources stores the application’s views, localization files (for supporting multi-language) and raw assets (SASS, LESS, CoffeeScript, etc.).
1.6 storage Directory
This directory acts as a temporary storage for application. It holds generated views, cache files, logs, and many other things.
1.7 tests Directory
As name suggests, it holds all the tests we have created for the application.
1.8 vendor Directory
Vendor Directory is created by Composer and holds all the code of the packages we use in the project. Even the core Laravel code resides in this folder.
3. Laravel Request Lifecycle
Above diagram shows Laravel request lifecycle, i.e., how a request from browser passes through various components we discussed in previous section.
The diagram is self explanatory. If you will start coding directly without understanding the above diagram, you are sure to get confused. So, take some time to grasp this diagram. Once done, we are ready to take Laravel head-on from next lesson!!!