Warning: Work in Progress!

This site contains a a few lessons on Laravel 4. It's still in it's early phases. Besides, Laravel 4 itself is a moving target and a few things may have changed by the time you read this.

I will regularly update the content. Thanks!

Architecture of Laravel Applications

Laravel is referred to as a “full stack” framework because it handles everything from web serving to database management right down to HTML generation. A vertically integrated web development environment can provide a better experience for the developer.

The typical developer interacts with Laravel through a command-line utility that generates and manages the Laravel project environment. Laravel comes with an excellent command-line tool named Artisan that can be used to generate skeleton code and database schema stubs. Artisan handles everything from database schema migration to asset and configuration management.

Convention Over Configuration

One of the interesting features of Laravel is that it imposes some fairly serious constraints on how you structure your web applications. Surprisingly, these constraints make it easier to create applications - a lot easier. Let’s see why.

Laravel differs from other vertically integrated environments in its strong preference for convention over configuration. Whereas some Java, Python or PHP frameworks often require lots of XML configuration, Laravel requires almost none (or perhaps only a few lines of PHP) to get started. This aversion to configuration files makes for a very distinctive and recognizable code structure that is the same across all Laravel apps.

One Project Structure To Rule Them All!

It comes as no surprise that all Laravel projects have essentially the same directory structure - one in which every file has its designated place. By gently forcing this directory structure upon developers, Laravel ensures that your work is semi-automatically organized the “Laravel way”.

Figure 1.1 shows what the Laravel project directory structure looks like:

As you can see, this standard directory structure consists of quite a few subdirectories. This wealth of subdirectories can be overwhelming at first, but we’ll explore them one by one. Most of your work will happen in the app/ folder, but here’s a basic rundown on the function of each of the files and folders:

Top-level Folders Purpose
/app/ Contains the controllers, models, views and assets for your application. This is where the majority of the code for your application will live. You will be spending most of your time in this folder!
/public/ The only folder seen to the world as-is. This is the directory that you have to point your web server to. It contains the bootstrap file index.php which jump-starts the Laravel framework core. The public directory can also be used to hold any publicly accessible static assets such as CSS, Javascript files, images and other files.
/vendor/ A place for all third-party code. In a typical Laravel application, this includes the Laravel source code and its dependencies, and plugins containing additional prepackaged functionality.

As mentioned above, /app is where all the fun happens, so let’s have a deeper look at the structure of this directory.

Figure 1.2 shows the /app folder in detail:

File/Folder Purpose
/app/config/ Configure your application’s runtime rules, database, session and more. Contains a number of config files for changing various aspects of the framework. Most of the config files return associative PHP arrays of options.
/app/config/app.php Configuration for various application level settings, i.e. timezone, locale, debug mode and unique encryption key.
/app/config/auth.php Configuration that controls how user authentication will be performed in the application, i.e. authentication driver
/app/config/cache.php If the application utilizes caching to speed up response time, this is where you configure the feature.
/app/config/database.php Contains relevant configuration information for the database, i.e. default database engine and connection information.
/app/config/mail.php Configuration for e-mail sender engine, i.e. SMTP server, From: header
/app/config/session.php Configuration that controls how user sessions are managed by Laravel, i.e. session driver, session lifetime.
/app/config/view.php Misc. configuration settings for templating systems.
/app/controllers Contains the controller classes that are used to provide basic logic, interact with data models, and load view files for your application.
/app/database/migrations/ The migrations folder contains PHP classes which allow Laravel to update the Schema of your current database while keeping all versions of the database in sync. Migration files are generated using the Artisan tool.
/app/database/seeds/ The seeds folder contains PHP files which allow Artisan to populate database tables with reference data.
/app/lang/ PHP files containing arrays of strings to enable easy localization of the application. By default the directory contains language lines for pagination and form validation for the English language.
/app/models/ Models are classes that represent the information (data) of the application and the rules to manipulate that data. In most cases, each table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.
/app/start/ Contains custom settings related to the artisan tool as well as global and local context.
/app/storage/ The storage directory is used as temporary file store for various Laravel services such as sessions, cache, compiled view templates. This directory must be writable by the web server. This directory is maintained by Laravel and you need not tinker with it.
/app/tests/ The tests folder provides a convenient location for you to keep your application Unit tests. If you are using PHPUnit, you can execute all tests at once using the Laravel Artisan tool.
/app/views/ The views directory contains your HTML template files used by controllers or routes. Note that you should place only the view template files in this location. Other static assests such as stylesheet, javascript and image files should be placed in the /public folder instead.
/app/routes.php This is your application’s routing file which holds routing rules that tells Laravel how to connect incoming requests to route handler closure functions, controllers and actions. This file also contains declarations for several events including error pages, and can be used to define view composers.
/app/filters.php This file contains various application & route filter methods that alter the outcome of your application. Laravel has some pre-defined filters for access control and XSS protection.

A lot of thought has gone into establishing and naming the folders, and the result is an application with a well structured file system.

Here is what you get:

Model-View-Controller (MVC)

Let’s get a high-level overview of how Laravel applications work. You might have noticed that the standard Laravel application structure has an application directory called app/ with three subdirectories: models/, views/, and controllers/. This is a hint that Laravel follows the model-view-controller (MVC) architectural pattern, which enforces a separation between “business logic” from the input and presentation logic associated with a graphical user interface (GUI). In the case of Laravel web applications, the business logic typically consists of data models for things like users, blog posts, and the GUI is just a web page in a web browser. The MVC design pattern is very popular in the web development space.

There are three components to the MVC pattern:

  • The model - The domain that your software is built around. Models are based on real-world items such as a person, bank account, or product. If you were building a blog, your models might be post and comment. Models are typically permanent and will be stored outside the application, often in a database. A model is more than just data; it enforces all the business rules that apply to that data. For example, if a discount shouldn’t be applied to orders of less than $10, the model will enforce the constraint. This makes sense; by putting the implementation of these business rules in the model, we make sure that nothing else in the application can make our data invalid. The model acts as both a gatekeeper and a data store.

  • The view - The visual representation of a model, given some context. It’s usually the resulting markup that the framework renders to the browser, such as the HTML representing the blog post. The view layer is responsible for generating a user interface, normally based on data in the model. For example, an online store will have a list of products to be displayed on a catalog screen. This list will be accessible via the model, but it will be a view that accesses the list from the model and formats it for the end user. Although the view may present the user with various ways of inputting data, the view itself never handles incoming data. The view’s work is done once the data is displayed.

  • The controller - The coordinator that provides the link between the view and the model. The controller is responsible for processing input, acting upon the model, and deciding on what action should be performed, such as rendering a view or redirecting to another page. Continuing the blog example, the controller might look up the most recent comments for a post (the model) and pass them to the view for rendering.

Components of Laravel

A typical Laravel application consists of the above mentioned MVC components, as you can see below:

When interacting with a Laravel application, a browser sends a request, which is received by a web server and passed on to the Laravel routing engine. The Laravel router receives the request and redirects to the appropriate controller class method based on the routing URL pattern.

The controller class then takes over. In some cases, the controller will immediately render a view, which is a template that gets converted to HTML and sent back to the browser. More commonly for dynamic sites, the controller interacts with a model, which is a PHP object that represents an element of the application (such as a user, blog post) and is in charge of communicating with the database. After invoking the model, the controller then renders the final view (HTML, CSS, and images) and returns the complete web page to the user’s browser.

Laravel promotes the concept that models, views, and controllers should be kept quite separate by storing the code for each of these elements as separate files in separate directories. This is where the Laravel directory structure comes into play.

Design patterns such as MVC are created to make a developer’s life easier. This is where Laravel scores over plain PHP which doesn’t follow any sort of paradigm. If this discussion seems a bit abstract right now, worry not! After you start working with Laravel, you won’t even realize that you are working in a design pattern. It all becomes natural to you after a while.

Data Models

At the base of any application are the data models that describe the business rules of your application. Each piece of data is represented by using a database table. Laravel provides a few technologies to simplify access to databases.

Laravel connects the application data models and database tables by turning table rows from the database into PHP objects that can be easily manipulated. It also enables you to enforce business rules, describe relationships between the different data models in your application and so on. For example, a person’s family relationships can be described using Laravel’s Eloquent OR/M as follows:

class Person extends Eloquent
    public function mother()
        return $this->belongsTo('Mother');

    public function father()
        return $this->belongsTo('Father');

    public function spouse()
        return $this->hasOne('Spouse');

    public function sisters()
        return $this->hasMany('Sister');

    public function brothers()
        return $this->hasMany('Brother');