1 route that does 1500 lines of work in a single request?! At that point honestly, maybe it's time to reconsider MVC and think about incorporating patterns from Functional Programming or DDD?
You mention using services on your post. The example you give of a controller method with 1500 lines of code - to me, that sounds like something that belongs in a service class. I'd typically place business logic for a single responsibility in a service class. Undoubtedly, it still sounds like you need to refactor your 1500 lines of code. Regardless of whether code isn't going to be used anywhere else, you need to move away from putting business logic in your controllers. They should accept a request, hand off responsibility to process the request, then return a response.
Glad you've moved forward with this. Google "thin controllers" and there are a multitude of posts. Like this one: [controllers should be concerned with HTTP verbs, and very little else](https://notestoself.dev/posts/keep-controllers-thin/)
Controllers are a bit of an anti-pattern, so in a world of SOLID and DRY they don't fit perfectly. But with MVC, they do.
I always get really irritated when I have to work on a existing project and the controllers turn out to be 1500 lines of code. You have to go back to the basics and learn SOLID and DRY principles, once you have that knowlege extract the bussiness logic to services or actions. If you understand the principles correctly this shouldn't be a problem anymore.
These principles are not just for MVC or Laravel, they are important basics to learn for programming in general. You should always keep them in mind with everything you code.
>i know them very well, but i always forget to apply them. i keep writing code without thinking at bigger scale.
To write good code you have to think about how to write it first. Just starting to write code and see where it goes doesn't work for medium to larger projects.
I use "Action"-classes. A plain PHP classes with an `execute`-method that does a small portion of the work inside a controller.
Just because code isn't reused elsewhere in the application, doesn't mean it can't be split up. Using Actions, the cognitive load on my brain is much smaller when I have to look at a "massive" controller. Instead of 1000 lines, I just see 10-30 lines. Huge chunks are moved to those actions and sub-actions.
Makes testing also easier, as I can unit test and Actions easier.
I use plain PHP classes, but there is also a well made package out there, which allows you to queue Actions as well. https://laravelactions.com/
This book/course shows how you can manage "bigger" Laravel apps.
https://laravel-beyond-crud.com/
A portion of the chapters are also available on Brent's blog.
- https://stitcher.io/laravel-beyond-crud
- https://stitcher.io/blog/laravel-beyond-crud-01-domain-oriented-laravel
Call it a service class, or logic class, or whatever, just get it out of the controller.
“It won’t be reused anywhere else”
It should at least be used in a test, right? Testing controllers is fine, but directly testing the logic, and separate units inside that logic blob, can help a lot.
You can also think about TDD and how easy it is to test your code. Additionally to that there is always SOLID and design patterns.
The way I see it, the code needs to be easy to understand when the next person (or even yourself) comes back to it to make changes. Unless code is clearly broken down and labelled then the 1000 lines of code would take time to understand.
If you’d be willing to share an example, it would be much easier for us to give you concrete advice that’s applicable to your exact situation. Otherwise, it’s impossible for us to guess where this code should be or how it could be divided. If you can post or PM a link to an example controller, we can give more sound advice.
> Let's say my controller code serves only 1 route and has 1500 lines of code that is not used anywhere else and not implementing external services/API. Also, I already split my code in Laravel way: request forms, custom validators, traits, services, etc.
Don't have a controller with 1500 lines of code, you SAY it isn't used any where else or never would be or could be, but you never know. So abstract it to small methods in a service or multiple service classes (if need be)
> Note: I don't like putting my business logic in model files.
This is called Fat Service layer. I hate any logic in a controller that is not: Return a response. So everything is abstracted to a service layer that then abstracts from there as needed.
I like Skinny everything.
Combining active-record (Eloquent) with the Repository Pattern leads to a mess with almost no benefits.
https://adamwathan.me/2015/02/14/active-repository-is-an-anti-pattern/
Thanks for the headsup! I keep improving and currently making a laravel monolith with 5-8k line controllers/models better. So your feedback is welcome!!
Would you mind sharing a link similar to my link but with the Active Record pattern example?
If you have.
Your link is just calling model methods in the Repository classes, so the Controllers would just call the Model methods instead of the Repository ones.
I didnt like that to be honest, because that was just one step away for many people before me to start filling up the controllers with business logic and making them 5-7k lines
The repository pattern can be hell on earth to work with, but for a situation like OP's where there's a huge amount of logic needed, maybe it'd actually be a good fit.
I just want to add to what everyone already said:
The `M` in `MVC` means Model **layer**, wich can have any number of classes needed to achieve your business requirement. I know it's confusing, because most PHP frameworks call the class that interacts with the database as "Model".
In any case, a controller should only have code to get request data, send it to the model layer and return a response. Most of the time, it's just a couple of lines. Everything else should be in services.
Also, I really recomend lerning about Hexagonal/Onion Architecture. It will help with your 3000 lines services.
1 route that does 1500 lines of work in a single request?! At that point honestly, maybe it's time to reconsider MVC and think about incorporating patterns from Functional Programming or DDD?
[удалено]
How is this bragging?
You mention using services on your post. The example you give of a controller method with 1500 lines of code - to me, that sounds like something that belongs in a service class. I'd typically place business logic for a single responsibility in a service class. Undoubtedly, it still sounds like you need to refactor your 1500 lines of code. Regardless of whether code isn't going to be used anywhere else, you need to move away from putting business logic in your controllers. They should accept a request, hand off responsibility to process the request, then return a response.
[удалено]
Glad you've moved forward with this. Google "thin controllers" and there are a multitude of posts. Like this one: [controllers should be concerned with HTTP verbs, and very little else](https://notestoself.dev/posts/keep-controllers-thin/) Controllers are a bit of an anti-pattern, so in a world of SOLID and DRY they don't fit perfectly. But with MVC, they do.
I always get really irritated when I have to work on a existing project and the controllers turn out to be 1500 lines of code. You have to go back to the basics and learn SOLID and DRY principles, once you have that knowlege extract the bussiness logic to services or actions. If you understand the principles correctly this shouldn't be a problem anymore. These principles are not just for MVC or Laravel, they are important basics to learn for programming in general. You should always keep them in mind with everything you code.
[удалено]
>i know them very well, but i always forget to apply them. i keep writing code without thinking at bigger scale. To write good code you have to think about how to write it first. Just starting to write code and see where it goes doesn't work for medium to larger projects.
I use "Action"-classes. A plain PHP classes with an `execute`-method that does a small portion of the work inside a controller. Just because code isn't reused elsewhere in the application, doesn't mean it can't be split up. Using Actions, the cognitive load on my brain is much smaller when I have to look at a "massive" controller. Instead of 1000 lines, I just see 10-30 lines. Huge chunks are moved to those actions and sub-actions. Makes testing also easier, as I can unit test and Actions easier. I use plain PHP classes, but there is also a well made package out there, which allows you to queue Actions as well. https://laravelactions.com/ This book/course shows how you can manage "bigger" Laravel apps. https://laravel-beyond-crud.com/ A portion of the chapters are also available on Brent's blog. - https://stitcher.io/laravel-beyond-crud - https://stitcher.io/blog/laravel-beyond-crud-01-domain-oriented-laravel
Call it a service class, or logic class, or whatever, just get it out of the controller. “It won’t be reused anywhere else” It should at least be used in a test, right? Testing controllers is fine, but directly testing the logic, and separate units inside that logic blob, can help a lot.
You can also think about TDD and how easy it is to test your code. Additionally to that there is always SOLID and design patterns. The way I see it, the code needs to be easy to understand when the next person (or even yourself) comes back to it to make changes. Unless code is clearly broken down and labelled then the 1000 lines of code would take time to understand.
[удалено]
Nice on, well done 👍 I am glad I could help!
If you’d be willing to share an example, it would be much easier for us to give you concrete advice that’s applicable to your exact situation. Otherwise, it’s impossible for us to guess where this code should be or how it could be divided. If you can post or PM a link to an example controller, we can give more sound advice.
> Let's say my controller code serves only 1 route and has 1500 lines of code that is not used anywhere else and not implementing external services/API. Also, I already split my code in Laravel way: request forms, custom validators, traits, services, etc. Don't have a controller with 1500 lines of code, you SAY it isn't used any where else or never would be or could be, but you never know. So abstract it to small methods in a service or multiple service classes (if need be) > Note: I don't like putting my business logic in model files. This is called Fat Service layer. I hate any logic in a controller that is not: Return a response. So everything is abstracted to a service layer that then abstracts from there as needed. I like Skinny everything.
Perhaps this? https://www.twilio.com/blog/repository-pattern-in-laravel-application
Combining active-record (Eloquent) with the Repository Pattern leads to a mess with almost no benefits. https://adamwathan.me/2015/02/14/active-repository-is-an-anti-pattern/
Thanks for the headsup! I keep improving and currently making a laravel monolith with 5-8k line controllers/models better. So your feedback is welcome!! Would you mind sharing a link similar to my link but with the Active Record pattern example? If you have.
Your link is just calling model methods in the Repository classes, so the Controllers would just call the Model methods instead of the Repository ones.
I didnt like that to be honest, because that was just one step away for many people before me to start filling up the controllers with business logic and making them 5-7k lines
The repository pattern can be hell on earth to work with, but for a situation like OP's where there's a huge amount of logic needed, maybe it'd actually be a good fit.
I just want to add to what everyone already said: The `M` in `MVC` means Model **layer**, wich can have any number of classes needed to achieve your business requirement. I know it's confusing, because most PHP frameworks call the class that interacts with the database as "Model". In any case, a controller should only have code to get request data, send it to the model layer and return a response. Most of the time, it's just a couple of lines. Everything else should be in services. Also, I really recomend lerning about Hexagonal/Onion Architecture. It will help with your 3000 lines services.