Laravel Controllers: Refactor Duplicate Code (Two Ways)

I want to show you two pretty typical examples of duplicate code in Controllers, and how/where to extract it.

- - - - -

[DavideBorsatto]

Don't do this.
You'll end up with a bloated and unmaintainable base class with dozens of methods that are useless for 99% of the controllers inheriting from it.

[phread]

Instead of the "experts" stating that this is not the way to do it, that their way is the best and/or the only way.. How about if you state your "choice", why it is your choice, where we could find more information about your "choice", give us a link to your YouTube video demonstration of your choice, and please stop telling us HOW we NEED to do it your way.  

Some of us like to hear about and learn different approaches/solutions, what the approach gives and takes, and we can then make a choice that we feel is best for us and/or our situation. This video does a great job explaining and demonstrating a solution to minimize code that we could impliment. He didn't say that we had to do it this way....

If you have such a problem with these videos, maybe you should leave this channel instead of beating on him for taking the time to help us.

[elarrim]

What about Traits? I think the best way is to use them!

[chillywilly]

this was so simple! thank you. I've been learning a lot about DRY and trying to implement in my laravel API

[dalisaacs]

The method in de Base class should be protected not public. Great job.

[belce]

Thank you as always. Don't stop now! Keep working!

[rexrex]

Thank you dad. I needed to refactor my controllers.

[sfetlioOo]

From Private to Protected is more logical change. Public methods at the controller should only be used to process all the control logic of a matching route

[EsronDtamar]

I don't like this approach of using the base controller to share code between controllers because the method will be "hidden". Another developer may not know about the method and re-implement it. When I want to share a method between controllers I usually create a Trait. The Trait needs to be imported, that makes the presence of the method more clear. What is your opinion about it?

[meerajadhikari]

Would love to see a video on Trait for File Uploading in Laravel
Great work sir

[SilveraStarbreeze]

You should use Route-Model binding and Request class to validate request. Then create trait for Cart controller with save method and pass validated data instead of Request object.

[kickass]

Nice video. Would you look at Laravel Jetstream and make a tutorial video for it?? Thanks!

[adarshchacko]

Just a thought... The second illustration of refactoring where a function is written in the BaseController... Wouldn't it cause unnecessary redundancy i.e. the function getting unnecessary loaded even if I am not using that function in a Controller... Any Thoughts ??

[abhijitpal]

Sir you provide very helpful topic. 👍🏻
I have a query sir. We can use trait also for making reusable code, say "to get store specific product ids for showing product, validating before adding into cart or place order". Please correct me if trait holds some other logic or use for other purposes. Thank you.

[amrullahdev]

But . Is this would good practice if we put more function on controller??

I think that a good alternative to the second way you mention would be to create a Trait, and in this way load it only in the controllers that require it, since by adding this code to Controllers.php it is available in all controllers unnecessarily.

[dimitar]

Where is firstOrNew() in this tutorial? :)

[soniablanche]

wouldn't it make more sense for the save method to be static since you're not using the "this" variable ?

[AugustoTitan]

I like to extract that shared saving logic to a 'process' or 'execute' method on the form request class.

[bhaidar]

What about using Repositories? Have them auto-injected in the constructor.