Laravel 6 Advanced - e7 - Repository Pattern
ฝัง
- เผยแพร่เมื่อ 20 ต.ค. 2024
- The Repository Pattern is a common refactor that you may encounter in large Laravel applications. While it is not ideal for small to medium projects, it's a perfect solution for those applications that need an abstraction of the data layer.
For the best experience, follow along in our interactive school at www.coderstape...
DigitalOcean Referral
m.do.co/c/7dce...
Hit us up on Twitter with any questions or comments @codertape ( / coderstape )
About This Course
Ready to level up your Laravel skills? This series is for you, follow along as we uncover the advanced Laravel features that actually make Laravel the most popular php framework. We'll have lot of tips and tricks along the way. Are you ready?
this is crazy dude. hope you have good health to create more videos. I learn a lot from your videos.
Dude, that map->format(); is genius, Wow
Also I've never know that we can ->diffForHumans() from carbon, thanks so much
These advanced series are very helpful. Thanks!
Happy to hear that. More advanced topics are much more time consuming in preparation leading up to recording the lesson.
@@CodersTape Thanks for your work Victor, what about another Udemy course applying those advanced concept ?
We understand that it is more time consuming, but you know you've got 1 more subscriber just now (me).
I'm sure you'll get alot more subscribers until this series end, but please make more videos.
Man, I watch A LOT of educational videos on coding (php, js, laravel, vue) and you are the best.
your practical explanation is phenomenal. Keep up the good work please, people like us depend on you.
where were you, finally I found someone that knows pure implementation and architecture.
I never comment on anything, but this series is just too helpful. You are my new Laravel teacher. Keep it up and thank you very much. You are awesome!
This course is amazing. Not the usual blah-blah most good laravel devs already know. But really insightful, solving real-life problems where you were thinking as a dev, there should be a nicer solution for this!
The best coding channel out there. I hope you post more videos as you used to.
I never not like every single video i watched from this dude. Thanks a lot bro.
Crazy good content, thanks a lot for posting this. The quality of this video is unreal. God bless you man!!
Thank u so much, we need people like you in this world
Watched this video to fresh up my memory on repositories and honestly you make great videos and your explanation is to the point. Love your style. On the subject though i do find that the only reason you should use repositories is when you expect to swap out your database for something else. Other than that i stick with model query scopes for the repetitive query's (powerfull for their chainability) and use resources to format them. Even on very large projects. You could still use repositories in combination with these, but as said, the only added value is data driver independency.
*Edit*
Looks like this has been said a few times. Either way, it boils down to project requirements and personal favor. There is no "right" way.
Absolutely.
Cool, unfortunately beginners take Repository as granted, glad that you pointed out that it is meant for larger apps!
Collection()->map->formatCallback()? and you dont kidding? Freakin awesome! That save me at least 1000 rows of code! Awesome! Thank you so much!
I love your tone and the content here
It's the first time I get to clearly understand Repositories.
I cannot pass to the next video without congratulating you and thanking you for such amazing video/explanation.
👏🏼👏🏼👏🏼
Thanks
well, you are still not, because repo pattern is not needed when using laravel
I will definitely implement the format function, I feel like I've been repeating myself a lot on database queries. Thanks!
Experiment Fractal
Interface implementation was my best part, loved it!
you're the best ever in explaining leravel
If I could to press "Like" twice, I would do it! Awesome tutorial as always.
Really amazing!. What about next point after implementation the interface?. Even without the interface we can do the same things. Then what's the purpose of the interface here?.
The repository should only be used to reterive the data.
It's a common mistake that some developers use repositories for storing/updating/deleting, but it’s not meant to be like that.
If you need to store/update/delete then you have to have a persistent layer.
I think Doctrine did the best implementaion of repositories.
In literature you find that the main purpose of repositories is to be a layer between your data mapping and the business logic. Its totally fine to store/update/delete date there. See stackoverflow.com/questions/57340681/should-we-save-update-models-in-repository-pattern
So what are we supposed to use instead of repos?
Great great video please make more advance video. You are really professional programmer.
You are incredible ! I asked for a video on it in your last video and you did it. Everything is clear ans precise. God bless you!
Very informative! I've been using using model repositories for a long time now, and this is a good tutorial for those who haven't tried it yet. This is useful specially when doing reports.
I was smiling while watching your video and thinks how a person could be so good at ♥️
Thank you
Nice video. I really learn a lot. I wonder why people gave this a thumb down
Thanks you for this video. I learned a lot.
However, I read some blog where the Repository is connected with the ServiceLayer. If I'm right then can you please make a video on how Repository and ServiceLayer works together on big projects.
Thank you again 😊 you are the best Laravel tutor.
Thank you, bro!!! You are awesome! I learnt everything I'm confused. Thank you for your lessons. Sincerely, Sanjarbek from Uzbekistan.
Thank you very much for these videos 🙌. I have read many times about the repository pattern, but this is by far the best explanation I have found.
This is the best quality content coding pattern
awesome , can you make more videos like this ? implementing design patterns and advanced php and laravel technics are awesome . Thanks again
Very well explained. Useful content.
Learning more advanced things in this advanced laravel series, out of the box :) .... Need a tutorial on Service Pattern implementation
Just totally love all your tutorials. Keep it up.
Excellent explanation, grasped it immediately.
This is why i love Laravel. Thanks for your good videos :)
I think for those who don't potentially change their projects databases, a cleaner way is to implement a eloquent based repository design pattern, that works specifically with laravel eloquent, and just so much cleaner and readable. For a large projects which may be deployed with different types of dbs, a middle layer like the repository interface design pattern is almost like a must go-to idea.
This is very useful. I learnt a lot. Thanks for the video.
thanks for creating such amazing video , i really love the way u clear concept in depth .
that's greate, greate series, greate demonstrations and easy to understand, thanks man :))))
That was awesome , thanks , these Advanced video series are awesome .
Your videos are simply the best, thank you
An extremely useful lesson, thank you, Victor!
Thanks a lot. Finally I understand repositories :))
100% Perfect !!
Thank You very Much Bro !! :D
12:19 You can avoid mixing transformers into repositories by using an external transformer.
In this case, the fractal package would be amazing to use.
May I ask where they are going to be called when formatting? should it be on the controller? or on the repository?
This is fr**king awesome my friend! I hope that someday or in the future that you will create a video on SOLID pattern in laravel. Btw You are the best
Thanks
@@CodersTape have you big man?
Great explanation about repository pattern :-)
Min 21:00
For those that can't load the provider when registering it in app.php file (test the provider with dd("plainText"))
You can do:
php artisan config:clear
php artisan clear-compiled
composer dump-autoload
If composer is failing, just delete the "dd("test")" in your provider
This map->format() blow my mind. That’s incredible video. But I still have some confusions:
I knew about this pattern, but still don’t understand why this is necessary.
Does it put all of logic to get data from Model to Repository?
What pros and cons when put all logic in Model instead of Repository?
Thank in advance
truthfully, I think it's a design decision more than anything. I particularly like heavy models and don't use repository patterns. One use case I can understand is when you are managing several different data sources and need to access them equally. Example might be news, let's pretend you are receiving news feeds, one is coming as an RSS feed, another is content written in-house and maybe 3-4 different sources. Repository will make the consolidation easier because they can be treated differently but accessed with the same API.
Coder's Tape
You are my new fav teacher. Great explanation !!! Thanksssss
@@tonviet712 Thanks!
Another good one! Keep it up bro! God bless you
Quick note. You bind interfaces in register() method of the service provider
WONDERFUL DUDE! KEEP GOING! U'RE A MAN!
Very helpful , I was waiting for it thank you so much, really appreciate all the valuable content you provided thanks again!
My god dude! thanks so much!! this video clarified me a lot of things. Love ur channel and content! cheers
I think repositories are also beneficial for testing. When you have the data layer coded against an interface like this, it becomes easier to mock it while testing. Depending on your needs, I think you might want to be able to separate tests that will reach the database from tests that just see if your basic functionality is working or not.
mind blowing video I have ever seen in the youtube
Very good explanation 🎉🎉
great stuff, but how would you combine repositories with API resources?
hi there, it's been long that you haven't published a video, I love your content, please start making videos again :)
I find formatting with Resources is much more flexible
I would honestly keep that format method within the Repository, as when you're writing a new concrete implementation of the repository, you might miss out on that specific business rule.
Awesome. You could've used Eloquent resources instead of format() right?
Hi Victor,
about interfaces, I was wondering... At my work (we use symfony) instead of creating a service that says "when I ask for this interface give me this implementation of it", we pass still require the interface (e.g. in some constructor) but, in the dependency injection configuration we pass the implementation we need in that particular case. This way we can use different implementations at the same time (e.g. a mailer instance could use SMTP and a different one might use Mailgun instead). i guess you can achieve that in laravel as well right?
Great! But.. this actions implemented in the repository can not be implemented inside the model? What s the difference? Thanks!!
The difference is that if you don’t want to use a database or Eloquent, you can’t use the model. You can write a flat file implementation for example or use Redis or anything else you can think of to provide the data, not just a traditional database. It can even be provided by an API.
Thanks for this great episode!
Wow! This is amazing! You are a god!
Is it really necessary to call/assign the CustomerRepository in the constructor or optional? Wouldn't it make the controller a little bit slow since every time we call the controller, the constructor also runs.
Hi there, what specific Phpstorm you are using? Thank you!
I have implemented the repository pattern before and this has been really helpful to add to my understanding. However, some folks somewhere on the internet claim that it should rather be a service layer and not repositories. I recently had to refactor one source code to reflect *services* instead of the *repositories* I had already implemented. I need help understanding these further.
The service layer is the abstraction of the controller where the repository is the abstraction of the model. Typically you inject a repository into the service layer so you would still need both and it's just yet another abstraction layer between the view and the controller. So the order would be
Controller > Service > Repository > Model
is it better? I can't agree that it is in most cases. I think it's just hiding away bad code design but I am open to seeing some code samples. :)
@@CodersTape Wow, that's quite interesting. I am implementing a payment gateway (API) with an ecommerce app where I would like to have a lot of the business logic in the services and then manipulate the data using Repositories. But while following the above structure, *Controller > Service > Repository > Model* where will FormRequests come in for validation?
thanks for your explaination for this pattern and it helps so much but i actually have some questions.
i know the reason for using the repository pattern but isn't this is why we use services classes ? For example " Making a UserService Class and inject it in controller and retrieve the users like : $this->userService->getAll() ?
And why using the map method to format the response and not use the resources ?
Mannn i really love this course!!!
just a awesome video bro!! thanks a lot bro
This is a great ep. Thx for showing us this. Would you make a video on caching?
If more than one class implements the CustomerRepository then in boot method of the provider we should register both of them (the interface with the first class and the interface with the second class) ? For example you can implement the interface with 2 classes one with pure eloquent ORM and second class with query builder
i hope i've seen your channel before my project... life shouldve been way easier
I am wondering that in this case, what is correct when we put the interface’s binding in ‘boot’ or ‘register’ function?
I readed that Repository pattern just receive data and not save. Is it true?
With this implementation, isn't the repository tightly coupled to Eloquent? why not DI?
dude come back and create amazing tutorials for us.
Thanks for sharing. This repostories like Helper, are we use without construct
Like "use App/Repostories/TestRepostory"
I was use like this, some 5.x version in laravel
what is the plugin that you use to initialize the field? thanks
If I will not use interface for repository and directly inject repository into controller then is it correct? Or is it compulsory to use interface with repository patterns? Or what is benefits to implement interface in repository? I bit confused. Please help me to clear this confusion. Thanks ☺️
Thanks so much for this tutorial
you are awesome dude
Thanks! Happy to help
it is a very nice course, thanks!
using request() in repository very nice
Eloquent is already a repository isn't it? Does it make sense to create another repository above the repository?
I do not agree on the part of format and transform. You can't choose format, formating is for dates for examples. What we are doing with this data is transforming it . But the tutorial and not only this one, all of them are awesome!! Keep up the great content.
Something else is that the request has nothing to do with the Repository. The repo is just a middle layer between the database and the Controller (I use this example to be more close to Laravel).
We need to pass all the data we need as params and never pass the Request outside of the Controller.
Hi, are there any plans for Docker lessons?
Hi, i have doubt. I am new to oops and laravel. Can we use traits to do format ?
Cool stuff, but I got a query: I there a way you can paginate the records either before or after you transform?
Very nice videos, thanks, I wonder if we register $this->app->bind(CustomerRepositoryInterface::class, CustomerRepository::class), whenever we call the CustomerRepositoryInterface via laravel container resolve, it always return then concrete CustomerRepository. My question is: what about another concrete class which implement CustomerRepositoryInterface ?
What's the difference between this and the resources? And how to handle more than one table?
question>
why dont use the model to write directly the methods there???
why extra layer of abstraction?
I think some of these concepts could be done by using Query Scope for readability if you are using Eloquent:
$customers = Customer::isActive()->orderBy('name', 'asc')->withUser()->get();
then pass that to API resource class for formatting:
use App\Http\Resources\CustomerResource;
return new CustomerResource::collection($customers);
Thank you !! very clear !
Dude, nice tutorials. Only 1 cent from me: I think repositories should be used entirely for one purpose - retrieving data. Update, store and delete functions should be found in the model or a Service.
I’ve seen it both ways in the wild. And I see both points of views.
@@CodersTape Yeah, I agree, it's a personal opinion. Anyway, keep up with the videos, they are absolutely amazing.