I read in some sites and articles, that using something like the "Managers" or classes with a lot of dependencies it's a bad practice.
So for example if i have a controller, and a repository and need to get the data of the database and make some changes or modifications and return to the controller to send the response, what is the best way?
Making one class for action? Make a class for functionality? making something like event domains? What is your approach on this?
FYI I'm using PHP in my current job. Any idea is welcome :)
Depends on the architecture I guess.
In my opinion it's better to have a manager structure than only controllers because you can easily switch between API or MVC so the businesslogic is not bound in the facade pattern and testable.
But I tend to use the managers only as a "state"-wrapper and the logic is inside of service classes who are actually stateless ... with a lot of traits so I can compose the functionality that I need but that increases the dependencies because of the traits.
I use a lot of metaprogramming as well and wrote some annotation contracts with factories and the manager gets the DI so i can mock everything ..... but still rather complex for an simple task.
In the end I'm as curious as you are if there will be any useful input because usually people just aim the designpattern canon on those issues or suggest a paradigm change like "use functional programming" or "AOP" ...
you've asked a very good question indeed :D
The thing with "managers" is that they "manage" a lot of stuff. So maybe you are tempted to create a:
The problem with this, in my opinion, is that this file will accumulate a lot of logic over time. It could become a very big file with all the rules overlaping each other, making it difficult to maintain. I don't know if this is the official name for it, but I call it "bottleneck".
I've found that a simple solution to this problem is separating small staff in it's own structure. Each "operation" in a separate structure.
The level of separation is up to you. They could be separate classes, separate files, and so on. The level os separation is a decision you have to make based on your needs. I like separate files because you won't get distracted by "old code" when you're making new stuff.
This structural separation of concerns is very important so your system doesn't become fragile over time. Think of systems where you fix something in a feature and break another. Also...you should be writing tests.
Be ware of your directories too. Popular "MVC" frameworks tend to give you predefined directories to work on, which doesn't scale very well. As the app grows, the directories also grow. This is also a bottleneck. You should identify and try to avoid all bottlenecks in your app.
A solution I've found that works for me is grouping small groups of functionallity in it's own directory. So the user related files could be grouped in a "users" directory, for instance.
These seem like simple advices but they have a huge impact on system health over time. I found out in the worst way that architecture matters, big time.