The Repository Pattern in Laravel
I recently came across a blog post titled – Laravel People (Generally) Don't Like Repositories. It reminded me of a project I worked on where the repository pattern was diligently followed to abstract away database interactions. Every single model had a corresponding repository interface and concrete implementation. For example:
UserModel.php
UserRepositoryInterface.php
UserRepository.php
Over time, a few things started becoming problematic.
Duplication
The methods in the base repository class looked like this:
abstract class BaseRepository implements RepositoryInterface
{
public function create(array $data) {}
public function update(array $data, $id) {}
public function delete($id) {}
public function all(array $columns = ['*']) {}
public function with(array $relations) {}
public function paginate($perPage = 50, array $columns = ['*'])
// ...
}
Do the methods look familiar? That's because they're mostly wrapper methods to their corresponding methods on the Eloquent Model
class (actually the Builder
class). While trying to extract away database logic, we were basically duplicating Eloquent's functionality.
Method bloat
Some repositories started getting bloated with very specific queries and long method names.
Say you needed to update values on two models, like Parent
and Child
. Invariably, you would end up with a method on ParentRepository
with a name like UpdateDetailsAndUpdateClassificationOnChild
.
There were dozens of methods like the above on some repositories, many with partially duplicated functionality that was difficult to abstract away.
Coupled to Eloquent
The entire premise of the repository pattern is to be able to easily switch between different data sources. But in our case, all repository functions were returning Eloquent models or an Eloquent collection.
In the end, I didn't see the point of using what essentially was a wrapper around Eloquent.
So, what’s the solution?
Thanks for all the problems, what’s the solution? asks the author on the blog post.
Well, first of all, you wouldn't do one thing from his example:
public function update(
UpdateProductRequest $request,
Product $product,
UpdateVariationsAction $updateVariationsAction
): ProductResource
{
// Don't do this
// <--
$product->name = (string) $request->string('name');
$product->price = $request->int('price');
$product->save();
// -->
$updateVariationsAction->execute(
$product,
$request->validated('variations')
);
return ProductResource::make($product);
}
Product
is being modified and saved directly from the controller. Try not to do this. You can follow a pattern already shown in the example above – Action classes. Here's how it can be refactored.
First we create an UpdateProductAction
class to abstract away the database logic. We also inject the existing UpdateVariationsAction
class into our new Action class.
class UpdateProductAction
{
public function __construct(
private UpdateVariationsAction $updateVariationsAction
) {}
public function execute(Product $product, array $validatedData): Product
{
return DB::transaction(function () use ($product, $validatedData) {
$product->name = (string) $validatedData['name'];
$product->price = $validatedData['price'];
$product->save();
$product->load('variations');
$this->updateVariationsAction->execute(
$product->variations,
$validatedData['variations']
);
return $product;
});
return $product;
}
}
Now the controller's update()
method is much simpler. All it's doing is, passing the model to be updated and the request data to the Action class.
public function update(
UpdateProductRequest $request,
Product $product,
UpdateProductAction $updateProductAction
): ProductResource
{
$updatedProduct = $updateProductAction->execute(
$product,
$request->validated()
);
return ProductResource::make($updatedProduct);
}
This pattern also addresses the comment about testing on the linked blog post. You can test the controller without seeding the database. All you need to do is stub or mock UpdateProductAction
.
Another huge benefit is that you can now hook into the UpdateProductAction
flow outside of an HTTP request. For example, you might want to create an artisan command to manually update a product as an admin task. Previously, you would've had to duplicate the functionality in your artisan command class. But now, you can just call UpdateProductAction
and you're done.
All patterns have their own set of trade-offs – there's no perfect one. You can still use repositories if you're willing to live with the trade-offs mentioned above. I chose to move away from them.
Liked this article? Share it on X