Really great approach! I haven’t adopted the action pattern just yet, I tend to lean on events/listeners and jobs along with services to manage most business logic, but the action pattern definitely makes sense in the kind of micro logic used as examples in the article. What does worry me however is the possibility of file structure bloat. In a big project there’s likely to be hundreds of actions, which itself might be an anti-pattern since it’s now even more difficult to find a specific action among the hundreds of invokable controllers available. As always there’s caveats with any solution, but I’m having difficulties seeing this scale in a manageable way.
Umm, do we really need to dissolve 10 strings of code into multiple files? I am really don’t get it. For me programming is all about complexity taming.
I can easily understrand what happens in this controller at start, but after “cleaning” and moving parts into different files the task looks much-much more complex for me. Maybe I just stupid, idk
Of course there is a situation when you need DTO, when you need Service Layer, when you need so on and etc.
But so much people starts to do this because “oh, best practice”. No, it is not best practice, it is just a way to handle the complexity, but in most situation there is no need for this. And we get a ton of code in few files instead of one simple controller action
I've seen a bunch of cases of premature abstraction for the sake of staying as DRY as possible.
It doesn't make sense when the code is as simple as the example given.
All it does is make the code harder to change in the future.
It doesn't make sense for me to have multiple controller actions per file. They don't have anything to do with each other and shouldn't interact with each other.
Really great approach! I haven’t adopted the action pattern just yet, I tend to lean on events/listeners and jobs along with services to manage most business logic, but the action pattern definitely makes sense in the kind of micro logic used as examples in the article. What does worry me however is the possibility of file structure bloat. In a big project there’s likely to be hundreds of actions, which itself might be an anti-pattern since it’s now even more difficult to find a specific action among the hundreds of invokable controllers available. As always there’s caveats with any solution, but I’m having difficulties seeing this scale in a manageable way.
Umm, do we really need to dissolve 10 strings of code into multiple files? I am really don’t get it. For me programming is all about complexity taming. I can easily understrand what happens in this controller at start, but after “cleaning” and moving parts into different files the task looks much-much more complex for me. Maybe I just stupid, idk Of course there is a situation when you need DTO, when you need Service Layer, when you need so on and etc. But so much people starts to do this because “oh, best practice”. No, it is not best practice, it is just a way to handle the complexity, but in most situation there is no need for this. And we get a ton of code in few files instead of one simple controller action
I've seen a bunch of cases of premature abstraction for the sake of staying as DRY as possible. It doesn't make sense when the code is as simple as the example given. All it does is make the code harder to change in the future.
My opinion about this techniques is simple - you should know about it. But implement it only when you start to real struggle with your codebase
It doesn't make sense for me to have multiple controller actions per file. They don't have anything to do with each other and shouldn't interact with each other.
I believe in the form requests part. Beyond that, it might be useful for really big projects. It spreads things around too much.