Repository pattern or actions while using the repeated functionality and keeping the code cosistence.
Generally I did not like the respository pattern. It makes code more complex and writing the more code for just a resuable functions and other stuffs.
Generally I did not like the respository pattern. It makes code more complex and writing the more code for just a resuable functions and other stuffs.
That is correct. If you lookup many past post on this question you will find myself and others have suggested staying with regular MVC and using laravel convention is better.
I wouldn't use that pattern.
Actions or controller methods either will produce the same result, that is preference.
Yeah, but how to tackle with the senior team member (who is the owner of the project created from scratch) and thinking to take some work form me on his working project and currently I am understanding the code and flows.
He advised me to keep the code consistent and best practices like repository pattern but I did not like it not even a single percentage of it. Also for other factors which he had mentioned I can stick to those but not to the repository pattern.
Than bring it up to him in a nice way that you do not think it is necessary to implement repository pattern since eloquent already abstracts data retrieval. But if they are set on it, the reality is you can't do much about it. Use it like they suggest, while a bit overkill it's not a bad pattern to have under your tool belt.
Yeah, thanks buddy.
It is his project, and if you are going to work on it, then follow the projects way of coding.
If you don't want to follow the coding practices of that project, then don't work on it.
Anything but repositories for me. Repositories are awful because you need to create new methods each and every time you want to do something different. Need a list of all users? Cool, add a getAllUsers method. Need to get users, but as a paginated list? Then you might create a getUsersPaginated method or similar. Now you want to sort users. OK, you either create yet another new method, or add optional sorting parameters to both your existing methods. What about filtering? It’s either yet more methods, or more optional parameters to your existing methods. And so on…
Actions are nothing more than self-handling commands that Spatie christened with a new name, and then everyone jumped on them as if it was some novel new approach. I’ll extract something to a dedicated action class if the action has a lot of prerequisites (such as validation, etc) that can maybe extracted out of the main “handle” method and into their own protected methods. If it’s something simple that can be encapsulated in a single method, then I might group related methods in a service class.
It completely depends on the project and the team.
Before Laravel, in the early 2000s, I used the Repository pattern extensively for enterprise projects. Nearly 25 years later, that same codebase is still in use and has been reused across multiple frameworks. At the time, I evaluated the Active Record pattern and found that it did not align with the project’s goals.
Laravel uses Eloquent by default, which largely follows the Active Record pattern and was chosen intentionally.
If the project is a large, long-living enterprise application that predates the Laravel framework, I would agree with your senior team.
you need to adopt the standards of the project unless you can jointly agree to change the approach.
Please or to participate in this conversation.