Practical use of orm. Where? Model? Controller?

Question

Doctrine ORM

Who has any arguments about using orm. Specifically interested in the question of calling methods of the query builder or AR.
Call the view code in the controller: or put such things into the model, while creating some api, like this:
Objects::where('votes', '>', 100)->count();

class Objects extends Illuminate\Database\Eloquent\Model {
    protected $table = 'objects';
    
    public function getObjects() {
        //еще ряд каких-то действий
        //...
        return Objects::where('votes', '>', 100)->count();
    }
}

and call later
Objects->getObjects();
The example is exaggerated to achieve simplicity. I am not tied to a specific framework, the essence of orm is the same for them.

Answer 1

In the MVC paradigm, data is manipulated in the model.
I would describe MVC as a small company that has a C-secretary who takes the order and passes it to the M-boss, he in turn tells the V-artist what and how to draw. The resulting masterpiece V hands over to C, who gives it to the client.
"Students and schoolchildren, I ask you to continue playing Dota and not be distracted by my question."
A prime example of a prejudiced attitude that needs to get rid of ..

Answer 2

The main problem is that the popular PHP frameworks don't have a model at all.
And the same ORM is called the model.
Accordingly, it is basically impossible to refuse the use of ORM in the controller. And the very ideology of the framework inclines to the fact that the controller is the model - in which all the business logic is written.
In the case of Laravel, we get
From this it becomes clear that the problem with Query Builders is petty and far-fetched. And to solve it, it is enough to apply common sense - if the call is single-line and readable, then we pull it right in the controller. If it's more complicated, we make a separate method in the "model".

Answer 3

In really complex projects, it's better not to use the query builder in the controller, everything should be done in the models. At the same time, even the model is usually divided into a pure model and a repository that carries data.
There are few such projects, usually your second method is enough, you just need to get rid of the class name by replacing it with static. There is also a scope, to put all sorts of conditions there.
Well, for many projects, noodles with a qveri builder right in the controller are enough, such things can then be refactored as needed, since modern IDEs do this once or twice.
IMHO, you should not bother, do what is more convenient now, and then through refactoring you will come to the form you need for the project.

Answer 4

I use a bunch - thin (tonic) controllers.
Therefore, in the model

Answer 5

I use separate classes for this, Model and ModelManager, in the first CRUD functions in the second everything else