<

div class=”section” title=”The need for the Factory pattern”>

<

div class=”titlepage”>

The Repository pattern

The Repository pattern is usually used to create an interface between two distinct layers of an application. In our case, the developers of Laravel use this pattern to create an abstract layer betweenNamespaceItemResolver (the class that resolves the namespaces and understands which file is in which namespace) and Loader (a class that requires and loads another class into the application). The Loader class simply loads the given namespace’s configuration group. As you might know, nearly all of the Laravel Framework code is developed using namespaces.

<

div class=”section” title=”The need for the Repository pattern”>

<

div class=”titlepage”>

The need for the Repository pattern

Let’s assume you’re trying to fetch a product from your database using Eloquent ORM. The method will be something like Product::find(1) in your Controller. For abstraction purposes, this approach is not ideal. If you now put a code such as this, your Controller knows you’re using Eloquent, which ideally shouldn’t happen in a good and abstracted structure. If you want to contain the changes done to the database scheme so that the calls outside of the class do not reference to the fields directly but through a repository, you have to dig all codes one by one.

Now, let’s create an imaginart repository interface (a list of methods that will be used in the pattern) for the users. Let’s call it UserRepository.php:

<

div class=”informalexample”>

<?php namespace Arda\Storage\User;
 
interface UserRepository {
   
   public function all();

   public function get();

   public function create($input);

   public function update($input);

   public function delete($input);

   public function find($id);

}

Here, you can see that all the methods’ names used in the Model are declared one by one. Now, let’s create the repository and name it EloquentUserRepository.php:

<

div class=”informalexample”>

<?php namespace Arda\Storage\User;
 
use User;
 
class EloquentUserRepository implements UserRepository {
 
  public function all()
  {
    return User::all();
  }
 
  public function get()
  {
    return User::get();
  }
 
  public function create($input)
  {
    return User::create($input);
  }

  public function update($input)
  {
    return User::update($input);
  }

  public function delete($input)
  {
    return User::delete($input);
  }

  public function find($input)
  {
    return User::find($input);
  }
 
}

As you can see, this repository class implemented our UserRepository that we created earlier. Now, you need to bind the two so that when the UserRepositoryInterface interface is called, we actually acquire EloquentUserRepository.

This can be done either with a service provider or by a simple command, such as the following, in Laravel:

<

div class=”informalexample”>

App:bind(
   'Arda\Storage\User\UserRepository',
   'Arda\Storage\User\EloquentUserRepository'
);

Now, in your Controllers, you can simply use the repositories as Use Arda\Storage\User\UserRepository as User.

Every time the controller uses a User::find($id) code, it first goes to the interface, and then goes to the binded repository, which is the Eloquent repository in our case. Through this, it goes to the Eloquent ORM. This way, it’s impossible for the Controller to know how the data is fetched.