Laravel Code Review: Why NOT Use Repository Pattern?

Repository pattern is one of the most misunderstood topics in Laravel, and in this video, I will explain why.

Also, starting TWO new experiments for code reviews!

Repository Pattern articles (READ THE COMMENTS!):

Related videos:

- - - - -
Support the channel by checking out our products:

[michazakrzewski]

I agree that „clear” Repository Pattern is over engineering, but using Repository class as a place where we make all our actions on database (creation, simple select etc) is good thing because this methods can be used in different places and second we can easly write tests using DI and creating mocks for Repository objects.

[nihadatakishiyev]

If Laravel communitity is one of the best out there nowdays, it's thanks to enthusiasts like you who is trying to make newcomers life easier. I appreciate all your efforts and wish you best of luck!

[flobbos]

I have to agree and disagree at the same time regarding your comments on the repository pattern. You are absolutely right that changing the underlying database never happens. It hasn't happened to me in the past 10 years. What does happen quite often though are code changes because clients need something added, the sorting changed or an extra relationship is needed. If that happens and I went with using Eloquent in controllers, I would have to go through the entire project to find every spot where the change needs to be applied. With a repository I just need to change it in one place.

That's a real life example that I am confronted with on a regular basis. From personal experience I have to say that a bit of over-engineering in the beginning of a project saved me many headaches during the evolution of a project.

[gustavolol]

From Brazil, thank you for the great video. Developing with Laravel, I found repository pattern to be necessary only in a few situations, where you need to build complex queries and because the key here is exactly what you said: "The Eloquent is a kind of repository itself.". For some other projects, languages and ORM this pattern should exists for great good.

[HelySousaOficial]

Initially, I'd like to express my gratitude for the time and effort you're putting to share so dense information about Laravel. I would like to contribute a bit by commenting that at 7:00 the store method is passing the $request object to the Repository (it could be a service as well). From the single responsibility principle perspective, isn't it an antipattern?

IMHO the $request object should be handled only in the controller and it should convert it to a PHP object ($request->validated, for instance) and pass it to the Repository. I think it happens also when the controller is dealing with accessing directly the database, such as in 5:08.

My main point about using Repository Pattern is not only the question of changing your database, I do agree with you that it hardly happens and I saw this happening just once, but concentrating the logic (again, it could be a service) in one point, so imagine that your application changes the business rules to show in the index just the items related to your company (multi-tenancy) or produced by you unless you're an admin user. You should change it in a lot more places if you have such database requests spread across your controllers, especially if your application grows.

I hope this can somehow contribute to the discussion.

[jopaymaymay]

You are one of the sexiest man in the Laravel community :) . Thank you so much for your efforts and contribution. I hope you all the best :)

[AhsanKhan]

Benefits of the Repository Pattern: - The customer(controller) is now separated (decoupled) from the data access.
Easy to write a test without side effects.
Modify and extend entities before they are passed on to the consumer.
A shareable abstraction resulting in less duplication of code.
Improved maintainability of our application.

[Jurigag]

The issue here is that CouponRepository here should be actually the interface, not a class. Then if you want you can even use a model as implementation of it, but it allows you to easly change this implementation to something else.

Also Active Record itself is kind of god class - it breaks heavily single responsibility pattern - it finds itself. Also repository shouldn't obviously accept the request. It should actually accept object of certain class, like PostRepository::store() method should accept object of class Post.

Also repository is part of Infrastructure layer, Services are part of Application layer - which shouldn't contain really infrastructure layer(implementations), there should be interfaces used(Ports) to infrastructure.

Also in bigger projects you want to separate actually the methods to find/get objects, like queries into separate interfaces and the repository which is used to write will only contain methods required for write(like store, and get the existing entity to update).

This way you can write to one database, but read from another, and have other process which synchronizes between them.

[thamibn]

Fully agree with you, people don't understand this pattern and it doesn't make sense to use it in Laravel with ActiveRecord(Eloquent) if you want to use repository pattern then use it with doctrine from the begging. Cause what people do is they always return an Eloquent model and they apply some filters and attributes and pagination on those Eloquent models which will break the whole application if we introduce new data source that does not return Eloquent models, even if there are test in place to avoid such trust me it will be a night mayor than anticipated, so you should know what your doing with this type of a pattern otherwise you just waisting time.

[VonBismarkOtto]

Laravel seems to be always bad idea to get work with best practice of code.
But anyway use repository to isolate your code from models. Becase Laravel implementation of AR provokes implicit model injection and the use of static methods. That makes your life harder in future and tends to destroy S from SOLID.
So, USE repository even without interfaces (you can add interface later when you want to have more than one implementation) - that simplify future and lower you code coupling.

[wijnandvanderweij]

I still like to use the repository pattern. Why? What if you want to change the storage engine? Like switch from Mysql to MongoDB par example. The repository pattern allows you to write methods like: findProductsByCategory of findByEmail. Ofcourse in smaller projects it seems like over engineering but in larger projects imho it adds flexibility. When you interface your repositories and use independency injection you can write decoupled code and not have a hard coded Model dependency in the controller.

[BenRiley]

I have always thought the repository pattern was over engineered as well but still use it. In my case I have a redis cache layer which is bound to the repository interface. The cache layer then calls the actual repository, and this seems to work well as I can cache all parts of my data in as large or small chunks as I wish. The approach was originally implemented in the AsgardCMS project, and worth a look.
Controller > Interface > Cache > Repository > Model > DB

[pedrolucca]

I have used this pattern in some medium and bigger projects and now i feel the same, that in most cases it`s over engineering. generally people need services and not repositories in all most cases.

[Laflamablanca]

The reply to this comment you mentioned at 11:00 sums it up perfectly on why you should be using the repository pattern regardless of whether you think you’re going to change your database or not.

[maquiavelotube]

although I have been using the Active Record pattern for a while now and honestly I find quite comfortable doing so, now I'm working on a company with 10 years code base and the Model classes became so bloated that the code is really hard to maintain. At first, the approach to move code to a service and leave the database code only in the model was ok, but then, is like the Product class (to use this video's example) became the database interface and the ProductService were the actual model class. I thing that in these cases, the Repository pattern is also the right fit, even more if the it is maintained by a larger team, because is easy for a new developer to know where the new code must go.

[johnnyw]

THANK YOU! I’ve spent the last month researching repositories. My first reaction was, “isn’t Eloquent already separating the storage layer?” You can change your storage method in your app’s config, and everything will still work. When am I ever going to change this system to something Laravel can’t support? And the code just becomes harder to follow and read, not easier. It’s a case of over engineering is almost every real life project. I love SOLID principles, but they’re *principles* not *laws*. You shouldn’t be making your codebase harder to work on in pursuit of a principle for the sake of it! YAGNI is also and important principle.

[manoelbueno]

I just landed into this video. I wanted to say for you that your video is just FANTASTIC! The level of detail and all the analysis that you did to explain the efforts pros/cons of building repository is just amazing and very clear to understand. I wish the best to your youtube channel. Very valuable content here. Congrats! Im subscribing.

[odunayoogungbure]

I've had discussions with fellow colleagues that the Repository Pattern is the most misused design pattern I've come across but they don't get it. I'm showing them this 🤝🏾

[erikguillen]

I use an extra layer. Use a "Service" class easier to test and to use in other places. Last time I experienced something kinda similar to Repository pattern is on Spring.

[sean_reyes]

how do you decide which topic to tackle ?

I would love to hear you talk about "Best way to handle different user roles with specific attribute"