Learning Laravel: What is Laravel?

In last week’s laravel post, I mentioned that Laravel is an open-source PHP framework that uses the model–view–controller (or MVC for short) architectural pattern.  This week, I want to drill down more on what that means.

What is MVC?

In MVC, the model encloses the application-related data.  It is where the your getters and setters would be.  The model does not deal with any actual business logic or how to display the data.  It is just the intermediary between the application and the database management system (ie MS SQL, MariaDB, etc).

The view in MVC is the part of the application that presents the data to the user.  It is often referred to as the presentation layer.  It contains the HTML that gets rendered within the user’s browser.  The view can contain some business logic but the majority of it is supposed to reside outside of the view.

The controller in MVC is what receives the HTTP request from the user and plays the part of traffic cop.  When the user requests a particular page, a view is what is rendered for the response.  That view is likely going to need to use data from the model but the view doesn’t request that data directly.  The controller requests the data on its behalf.  The flow of data can be bidirectional, also.  The data might flow from the controller to the model if the request involves a need to store or update a record.

MVC is great!  The separation of roles makes development easier (especially if a dev team is involved) than if your database requests, business logic, and rendered code were all just intermingled in individual PHP files.  You might notice that other frameworks use different architectural patterns (like Hierarchical model-view-controller, Model-view-viewmodel, Model-view-presenter, or Model-view-adapter).  For the most part, they are all just alternative attempts to get to the same basic place.

How is a Laravel application organized?

The first part of the application that we are going to look at is router.  Last week, we created a new Laravel app and used php artisan serve to make it available at http://localhost:8000/.  The resulting “hello world” app is what we are going to be pulling apart.  If you if you open the folder that the installer created, browse to routes subfolder, and open web.php, you should see what the “welcome” route consists of.

There are other types of routes in that folder but you can ignore them for the moment.  The only route in the file, so far is:

Route::get('/', function () {
return view('welcome');
});

It is pretty easy to grok what is going on here without knowing Laravel.  It is a route that covers get requests for whatever is at the root of the site and it executes a function that returns a view that is called “welcome”.

So, where is the “welcome” view defined?  If you go to the resources/views folder, you should see a welcome.blade.php file.

The welcome blade is what you see rendered on the site when you load http://localhost:8000/.

So, the next big question is how it connects to a database management system.  Let’s take a look at the database.php file in the config folder.

You should see a place to define a “default database connection” and definitions for the various possible database management systems that laravel supports (SQLite, MySQL / MariaDB, PostgreSQL, and MS SQL Server).  As a note to the folks using Oracle, don’t fret.  There are ways to get it to work, even if it isn’t officially supported. 😉

The definitions within database.php all reference values within your application’s .env file.  If you open your .env file, you should see these values.

This file contains system credentials, service details, and essentially all of your application’s secrets.  That is why it is so important to not commit it to git and generally not expose it to the outside world.  If you open your .gitignore file, you should see .env in there, already.

Going back to the database.php file, you will notice that all of the definitions look like this:

'default' => env('DB_CONNECTION', 'mysql'),

So, if the default database connection name is populated with the DB_CONNECTION in the .env file, why is there the second argument to that method?  It is there so that it defaults to MySQL if that value isn’t defined successfully in your .env file.

Last, let’s take a look at the database folder.

In here, you will find the application’s factories, migrations, and seeders.  If you return to the terminal and run the command php artisan migrate, artisan will look at that migrations folder, execute any migrations that haven’t yet been run, and in doing so it will create new database tables and columns.  This feature allows you to version your database’s schema just like you do with your code.  If you need to create a second copy of your application, you just need to rerun the migrations.

So, what is next?  In the next Learning Laravel post, I want to cover how to deploy a Laravel app.  Until then, if you have any questions, comments, etc, please drop a comment below.

 

 

[ Cover photo by Fotis Fotopoulos on Unsplash ]