If you know a couple of things about good development and best practices, you have probably heard about software design patterns.

You can define them as useful solution templates for a certain kind of problem, or to be more precise:

“In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.”


This extract is from the software design patterns page (http://en.wikipedia.org/wiki/Software_design_pattern) on Wikipedia.

Now, let’s focus on the second sentence.

A design pattern is not something that can be transformed directly into source code.

That’s the most important part because it explains many things. It is not something you learn specifically for Laravel or maybe for a certain language.

Absolutely, once you learned about design patterns, it is for life!

However, many people don’t like that kind of approach. They strongly believe in the Single Responsibility Principle, so every class must do one and only one thing. Nothing more!

Let’s be clear; I don’t want to bore you by adding my useless opinion in this long-time debate.

In the final part of this Tutorial, I will introduce a specific design pattern that can be really useful for improving a Laravel application—the repository pattern.

Hello, repository pattern!

You know that I like to explain a concepts with an example as a start. This is no exception.

Imagine that you are building an application for a warehouse. In this warehouse, you can store whatever you want and you probably have a model like this:

<?php namespace Warehouse;

use IlluminateDatabaseEloquentModel;

class Item extends Model {

  // properties and methods here...

You are probably using this model in a controller, like this one:
<?php namespace WarehouseHttpControllers;

class ItemsController extends Controller {

  public function getIndex()
    $items = WarehouseItem::orderBy('created_at', 'DESC')- >paginate(30);

    return view('item.list', compact('items'));


There’s nothing to say; it works, and you know it.

This is a cool solution for a simple project, the kind of project that you can call an application. However, what happens if we don’t have an Application, instead?

Imagine that the business you’re helping grows and the management decides to create a mobile application that must be used internally. You will probably need to implement an API for the other developers.

If you don’t know how to deal with something like this, you will soon start to write duplicated code. In your Rest API, for sure, there will be an endpoint items that does the same thing you did in the controller method such as:

$items = WarehouseItem::orderBy('created_at', 'DESC')->paginate(30);

Repeating the same code many times isn’t safe. You know it, right?

But no fear, hero! The solution is called a repository pattern.

The best definition of this concept is the one you can find on Martin Fowler’s website (http://martinfowler.com/eaaCatalog/repository.html):

“A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction.

Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes.”