Laravel Code Review: Why NOT Use Repository Pattern?

hello guys today we'll have another laravel code review but this time on a specific topic of repository pattern and in general i've switched from general junior code reviews to specific topic based reviews so wouldn't repeat myself with the same junior mistakes or the same advice it will be around some topics so each video i will choose one or a few topics to talk about but before we dive into the repository pattern review i have two important announcements here about junior code reviews in general so after i've done a few dozens code reviews on youtube and privately and discussing with you guys on twitter what could be the model of future code reviews and my mentorship i decided to make an experiment or in fact two experiments in one so this repository that i will review and i will talk only about repository pattern but this repository is public and i invite you all of you to join me on this review so in the description of this video i will link that repository it's public you don't need to be invited here and you can help that developer to improve their code how do you do that just go to the repository choose any file and if you see something that can be improved you just click here click this line and then reference in a new issue and you just create an issue with title something wrong and the description of things that could be improved if you have any ideas how to make it more convenient maybe you have some suggestions but that's how i would do that so reference the exact place in the code the exact line and then provide some feedback on what is wrong and what could be improved so that's the experiment number one and i hope it will be successful we'll see and we'll discuss a bit later in the week second experiment is for those of you who want to be reviewed who want your code to be reviewed and i receive quite a lot of emails and youtube comments like can i send you the code to review generally i'm kind of finished with general junior code reviews but again why don't we make a community and on twitter i've proposed that idea and we discussed it a few days ago maybe it could be a paid review program like someone wants their code to be reviewed pays like 50 bucks to someone and then another senior developer performs that review but then after discussing on twitter i realized that money would kind of spoil the whole thing here we are community here so why don't we build the community and let's try to do that so if any of you wants to be your code reviewed publicly as a first attempt as a first experiment i've created just a google sheet public google sheet how it works anyone who wants their code review put the repository url here let's zoom it in a bit public repository then any of your comments like what should be reviewed or what should be emphasized or what problems you have or what questions you have something like that and then anyone who wants to review just put in three things your github username when you reviewed the code and any comments you have of course i know it's a small text area so not much text would fit in here but just as an experiment i want to make sure that if we have some data so if we have repositories to review and if you have people that want to review them then i would transform that into some kind of project some kind of database like create a new small laravel project just for this and if i see some action here i will tweet the links to the public repositories on twitter to reach more audience of potentially senior reviewers and now let's move on to the review of repository pattern so today we're looking at the code of a simple eshop with admin area and specifically i want to stop at repository pattern so there is a coupons table where you can add a new coupon or you can manage orders in here or you can manage users or you can manage other stuff so pretty simple admin panel but let's take a look what's inside so in coupons table in the coupon controller we have something like this and here we see a repository pattern being used so instead of doing coupon all from the database we have coupon repository that does all the job for us inside of that coupon repository in the constructor there is a coupon model being passed and here's what happens so to get the list of the coupons probably the correct syntax by the way is this i think because it's not a static method so what it does in the controller we are injecting the repository and then this coupon can be used in all the controller methods so this coupon index gives us the list then in the store method this coupon store is the method that performs the storing of the data and then what else update is the same thing and coupon delete in this case for some reason repository wasn't used so in this controller's case repository is used just to take over the job of controller and make the controller shorter and perform all the tasks here in the repository but is it worth it if it's just a simple operation of order by why would you use repository instead of doing just in here coupon order by paging 8x5 so instead of doing repository you would do coupon order by id descending paginate like this and then you don't need any construct any repository anything isn't it shorter so i feel the repository pattern is a bit over engineering here instead of just using simple eloquent another example of over engineering in the same repository let's take a look at another controller order controller in here you see eloquent model being injected in the constructor of the controller and i have a feeling that this developer has read some fancy design pattern articles of best practices where a lot of stuff is injected and reused this way and in a minute i will explain the cases when those should be used this way but in this simple example why don't you use this order all here like this so injecting something just to have this order sounds like an over engineering to me and let's take a look at the third example third controller where that repository pattern makes a bit more sense so in the product controller there are a few things injected in the controller so repository and then the models of eloquent let's close the sidebar so in the index we're getting the products again using this product instead of just product eloquent but fine and where it makes more sense is in the store method so to store a product there are a few actions to be made so in product repository store we open that method and we create the product first of course this could be shortened with request validated for example but generally there are a few things happening here so creating the product then syncing the tags and then processing the images and then clearing the cache so if we put it all in the controller it would be a bit too long so probably the logic here was to offload that to repository pattern to repository class and the controller is just one line of store the product and then repository takes care of it all and that's fine but then this pattern should not be called a repository if you offload some action to a specific class it's more like a service class it could be any php class that you pass the request to and it does the job or it could be even a laravel job for that but again in this simple case even if we get the repository code into controller it won't be that long for example if we change this to request validated if it uses form request so we're getting rid of these lines then this is one line and then here we could probably make this as a service method separately because there's also upload image here which takes care of the uploads and i have a separate code review about file uploads by the way so i will link that in the description below but generally okay i would put these two lines in the controller and then image processing could be a separate job or separate service now let's get back to repositories how they should be used in general and what is all the hype about them i've googled around and found a few articles about laravel repository pattern and how it is explained with a few examples so let's take a look what is the general logic of repository being used correctly so in the controller instead of having post all or post find or fail you have not repository first you have an interface interface describes what methods will be in any repository that implements that interface so the main logic of repositories is to be changed with some other repository so for example if we go to product controller and you see this repository being injected that means that this could be changed to something else like some other product repository in the future like testing product repository or fake product repository or whatever and this should not be a repository class this should be interface class that this repository will implement then it makes a bit more sense let's take a look a bit deeper at the example so we have interface with those two methods then we have a repository that implements that interface and may or may not use eloquent model but it should be the same methods then in the controller you bind that interface that's the main thing that's not the repository class that's the interface and then you use this repository like it would be this product repository or something and then you need to bind those repository interface to the specific pattern so you need to tell laravel in your service provider or an app service provider that this interface is implemented by this repository and then someone else in the future or you in the future would be able to create another repository and change this one or change this in other condition like in testing somewhere to replace post repository with whatever else repository and the example here in this article provided what if you want to change post repository to post repository firebase so instead of eloquent you would use firebase engine to store the data and get the data and then you just change that to pulse repository firebase and that is a typical structural example of when the repositories are used and how they should be used but if you ever need to change your database engine from eloquent to firebase i'm pretty sure you'll have much more structural changes than just replacing that repository same if you want to implement your stuff with mysql versus mongodb versus another nosql engine versus whatever i'm pretty sure the repository will be the last thing on your list to make the changes in your application and i was struggling to find the thoughts how to explain all of that and i've googled i found a few articles with comments that will kind of prove my point there's one article about repository pattern from 2019 which explains roughly the same thing of replacing the repository with interface and here's the comment let's zoom in a bit when people advocate for repositories they often say what if i want to change mysql to something else and the question how many times have you heard of such a decision ever and even if it exists in real life it would be a pretty hard thing to implement and by the way i will link all those articles in the description below so that's one comment one example and another example on reddit from three years ago what's your opinion on service and repository let's zoom it in again and then three years ago one person said i used to be big on the repository pattern and by the way repositories were very popular when laravel appeared in laravel 4 i think i personally started with laravel with 4.2 and at the time a lot of examples were with repository pattern so that's where it started in the very beginning so there were a lot of articles and examples like this one so this repository and then do some action but as it is said in this comment there are so many unnecessary layers which is harder to read harder to change harder to understand for new developers and same thought if i ever needed to swap mysql for in 99 of cases it never happens and also this comment mentions my own thought from a few minutes ago end up making a service or something similar so if you need to offload the controller actions to somewhere it's probably more like a service than a repository because if done right and correctly repository should implement the interface with all the rules that i've just shown a few minutes ago and that's usually not what you want to do especially for junior developers that totally sounds like unnecessary over engineering to me so in short in 99.9 percent of cases you don't need repository pattern in laravel and another thought i've read somewhere now i didn't find that article the eloquent thing is kind of a repository itself so repository is a layer between controller and the database isn't eloquent what it is so instead of writing db table something or dbrosql you write user all or post all so in a way eloquent is already a repository itself or kind of a repository and then you're creating another repository on top why would you do that to yourself and finally i have another article about services in general article or video i will link them both in the description below about such cases and how to implement them in my way that's only one way that i'm proposing i'm not 100 right all the time and as usual there are multiple ways to implement things in coding but i will link a few of my recommendations below so that's it for this video i will remind you of two experiments that i've just started that you can participate in so review that repository i've touched only on that repository pattern but you can review and help that person to improve their code and another experiment if you want your code to be reviewed put it in here in the google sheet and the link is in the description of this video below or if you want to help to review anyone's code follow that google sheet changes or follow me on twitter and i will tweet some links there and then try to review someone's code and help them to improve their code let's try to make a community around junior code reviews and let's see what happens if you want to support me on my mission of doing daily videos code reviews and all of that stuff check out one of the three products you can see on the screen admin panel generator my courses which is 16 courses at the moment and livewire kit set of confidence see you guys in other videos

Channel: Laravel Daily

Views: 37,115

Keywords:

Id: giJcdfW2wC8

Length: 14min 21sec (861 seconds)

Published: Sun Mar 21 2021