Repositories for me and the dummies

I usualy don’t build any applications of a larger kind. Instend I spend most of my time building medium size sites
with WordPress. But that doesn’t mean that it’s a waste of time studying how to architect larger applications.
Once in a while, you might need to build some functionality that is more complex. Then it would be good to have, at least some knowledge, about design patterns and best practices.
We all want to avoid spaghetti code, don’t we?

There is however a lot of different concept to wrap your head around when it comes to things like this.
Repositories, or the repository pattern, is one of them and I belive that I’ve begun to understand at least the basic concept of this pattern.
In order to prove that for both you and myself, I’ll try to explain it.

What it is

As I understand it, a repository is basically a class that acts as a layer between the application and the database for example.
Okey, that’s not a very good description. I’ll try to explain the concept using an example instead.
Let’s say that we are using the Laravel framework and wanna fetch a user with the id of 1 from the database.
That can be accomplished by doing the following:

<?php
$user = User::find(1);
?>

We are using the Eloquent ORM to perform the database query in a very nice and simple way.
But instead of interacting directly with Eloquent, we could use an repository instead. That would make the code above look like this instead:

<?php
$repo = new UserRepository;
$user = $repo->getById(1);
?>

The repository itself would look like this:

<?php
class UserRepository
{
    public function getById($id)
    {
        return User::find($id);
    }
}
?>

Be aware of that all the code above is nothing more than pseudocode and won’t work if you just copy and paste it.
However, I hope that it demonstrates what I mean by describing a repository as a layer between things.
The result is exactly the same, you will receive the user with an id of 1 from the database. UserRepository is just a class with methods that calls the corresponding Eloquent method.

Okey, but why?

As I said, the result will be exactly the same, except there’s more code to write if you’re using a repository.
So why would you bother using a repository? What’s the point with it? As I see it, there’s two main reasons for doing it.

#1

The first and most important reason is that the repository will protect you.
Let’s say that your application grows and becomes very large and contains hundreds of .php files. You are using Eloquent methods in at least 50 of them, but you don’t know for sure.
What happens if a project manager tells you that you cannot use Eloquent anymore? Instead you have to replace Eloquent with raw SQL queries instead.
Without repositories, you’ll need to find all places in your code where you’re using Eloquent. That would be a painful process!
But if you were using repositories from the beginning, you would know exactly where to look.

#2

The second reason is TDD. A repository is easier to test since you can use a tool like Mockery to create a mock of the repo.

Another example

You have a site where users can log in using Facebook. What happens if Google suddenly buys Facebook and migrates all users to Google+?
Don’t worry! Since you have a repository containing the methods that you’re using to make calls to the Facebook API, you know what to do.

I hope that this explanation of the repository pattern was fairly understandable and not totally incorrect. As I said in the beginning, I’m still learning about this.