Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From \$16.50/m

The Repository Pattern in Laravel 5

The repository pattern was introduced for the first time by Eric Evans in his Domain-Driven Design book. The repository is, in fact, the entry point for the application to access the domain layer.

To put it simply, the repository allows all your code to use objects without having to know how the objects are persisted. The repository contains all the knowledge of persistence, including mapping from tables to objects. This provides a more object-oriented view of the persistence layer and makes the mapping code more encapsulated.

The only way to make your repositories work in Laravel (as a real repository—Eric Evans Domain-Driven Design book) is to change the default ORM from active record to data mapper. The best substitute is Doctrine.

The Doctrine ORM

Doctrine is an ORM (object-relational mapping) which implements the data mapper pattern and allows you to make a clean separation of the application’s business rules from the persistence layer of the database. Doctrine uses DQL, rather than SQL. DQL brings you object query language, meaning that instead of a traditional relational query term, you would have queries in object term.

It allows you to write the database queries in an object-oriented way and helps when you need to query the database in a way which can’t be achieved using the default repository methods. In my opinion, DQL is the most powerful way to keep in touch with your database.

Doctrine vs. Eloquent

Doctrine entities are just a plain PHP simple class and do not add overhead to any ORM inheritance. Doctrine manages your multiple query requests with the same inheritance without hitting the database, meaning the entity object exists for the entire request.

The other nice feature of Doctrine is that instead of migrating files to create the database schema, the database is automatically created to reflect the meta data in the entity annotations. On the other hand, Eloquent is less complicated and very easy to use.

A complete comparison between these two would necessitate a separate article. As you can see, a Doctrine object is lighter and more abstract. However, Doctrine will only fit specific projects, so it may bring you overhead at times. I believe it depends on the programmer to choose the best ORM for the app.

The Blog App

Now it’s time to create a blog app with Laravel. First, we need to set up Doctrine. There is a bridge to allow for matching with Laravel 5’s existing configuration. To install Doctrine 2 within our Laravel project, we run the following command:

As usual, the package should be added to the app/config.php , as the service provider:

The alias should also be configured:

Finally, we publish the package configuration with:

Now we’re done here.

Entities are important parts of the app App\Entities\Post.php:

Now it’s time to create the Repository, which was described earlier. App/Repositories/PostRepo.php :

The controller: App/Http/Controllers/PostController.php :

As you see, I’ve used the Flash helper to manage the messages (you can use Laravel’s). Regarding the Validator, I should add that you can create your own (as I do) or use the Laravel default, depending on your preference.

View files are the same as usual. In this sample view, the file seems like resources/views/admin/edit.blade.php :