|

Laravel Repository Pattern

repository pattern

The Repository Pattern can be very helpful to you in order to keep your code a little cleaner and more readable. In fact, you don’t have to be using Laravel in order to use this particular design pattern. For this episode however, we will use the object oriented php framework Laravel to show how using repositories will make our controllers a bit less verbose, more loosely coupled, and easier to read. Let’s jump in!


Working Without Repositories

Using repositories is not mandatory! You can accomplish many great things in your applications without using this pattern, however, over time you may be painting yourself into a corner. For example by choosing not to use repositories, your application is not easily tested and swapping out implementations would be cumbersome. Let’s look at an example.

Getting House Listings From a Real Estate Database

HousesController.php

This would be pretty typical code for using Eloquent to interact with the database which holds listings of houses for sale. It will work just fine, but the controller is now tightly coupled to Eloquent. We can inject a repository instead to create a loosely coupled version of the same code. This loose coupling makes it easy to swap implementations at a later time.


Working With Repositories

There are a fair number of steps to complete the entire repository pattern, but once you go through it a few times it becomes second nature. We’re going to cover every step here.

  • 1: Create the Repository Folder

  • We recently looked at a common Laravel File Structure you might be using. This creates a folder in the app directory to hold all of your domain specific files. For this example we’ll create the repotutrepositories within our app folder to contain our files. This also sets up our namespace structure which we will need to keep in mind for the files we create.

  • 2: Create Your Interface

  • The next step is to create the interface which will determine the contract our repository must implement. This just lays out the methods that must be present in our repository. Our Interface will look like the following. Note the namespace and methods we will use.

    HouseRepositoryInterface.php

  • 3: Create Your Repository

  • We can now create the repository which will do all of the heavy lifting for us. It is in this file that we can put all of our detailed Eloquent queries, no matter how complex they may become. Each method simply has a custom name so that in our controller, we can just write some very short code to get the desired result. Again note the namespace and the use House; statement.

    DbHouseRepository.php

  • 4: Create Backend Service Provider

  • For our controller, we are going to type hint an interface. We are going to be doing dependency injection, but by way of an interface essentially. What this means is that we need to register the interface with Laravel so that it knows which implementation of our interface we want to use. We’ll first use an Eloquent implementation, but later we’ll move to a File based implementation to show how we can swap implementations easily using an interface. We place this Service Provider in the same namespace as our other files so far.

    BackendServiceProvider.php

    This code basically says, when you see the controller type hinting HouseRepositoryInterface, we know you want to make use of the DbHouseRepository.

  • 5: Update Your Providers Array

  • Now that we have created a new Service Provider, we need to add this to the providers array within app/config/app.php. It may look something like this once complete:

  • 6: Update Your Controller for Dependency Injection

  • We have most of the groundwork in place. We can now update the Controller to facilitate injecting an implementation of the HouseRepositoryInterface. This will all us to remove any calls to Eloquent directly in the Controller, and replace those with simple custom method calls. Our updated controller might look something like this:

    HousesController.php

  • 7: Confirm Routes are Correct

  • For this example we simply set up a route resource like so:

  • 8: Update composer.json

  • If you have not done so already, make sure that the namespace we are referencing is in your composer.json. Note the addition of "psr-4":{"repotut\": "app/repotut" } which tells composer to autoload the classes within the repotut namespace.

    Don’t forget to run composer dump after updating composer.json!


Whoa! Nice work partner, let’s test it in the browser. We can visit http://localhost/repotut/public/houses and we can see that we have 3 houses for sale, each a different color.

Laravel Repository Pattern


Easy To Change Implementations

Let’s say in the future you decide that Eloquent is not the way you want to handle storing data with your app. No problem! Since you already laid out the ground work for using an interface, you can simple create a new repository and change the Service Provider. Let’s see how we can swap implementations.

  • 1: Create a New Repository

  • We’ll just use a quick example here. Let’s pretend this is a whole file system class which provides data storage via flat files. In our case, we’ll just put some simple logic in to test swapping implementations. Note that this class implements the same exact methods as the Eloquent version we tested prior.

    FileHouseRepository.php

  • 2: Update Service Provider

  • Now in the Service Provider, all we have to do is change one single line of code! We simply tell Laravel that now when you see the HouseRepositoryInterface, you will use the FileHouseRepository instead of the DbHouseRepository.

When we test it in the browser at http://localhost/repotut/public/houses we can see that the new implementation has indeed taken effect, very cool!
Repository Swap Implementation

Repositories Conclusion

As you can see, it seems like a lot of steps to get Repositories working in your application. There are a few steps involved, no doubt about it. If you are going to be responsible for maintaining a piece of code for the long term however, you are going to reap the benefits of taking the time to correctly architect your app in the beginning. Consider it a form of delayed gratification, which in this day and age seems like a forgotten art.