How to correctly implement a model in Symfony2 based on MVC?

Question

symfony

I figured out what is in the Symfony2 View, and where is the Controller, but I can’t figure out where and how to create my logic model? I know that there are doctrine entities in the Entity folder that provide an interface to the database with getters and setters, but this is not yet a model. The model should just describe the entire logic of work and not with one data table, but with all possible connections and restrictions. But where to take this model?
If separately in the Models folder, then how to access the service container in the model classes in order to use the same Doctrine if the model class does not inherit from Controller (this is a model, not a controller!)? Or is it necessary to implement the model “next to” Entity, inheriting classes from them? It seems to me that the main part of the logic should be in a separate model, and not in the controller, or am I misunderstanding something?
Please share the knowledge of experienced developers on this issue and help in this matter.

Answer 1

The logic of the model is usually placed in the service layer
. To work with the database, the repository classes are used.
Now an approach similar to yours with UserModel is popular, they create a class - a model manager, encapsulate the model repository there, EntityManager, etc ...
It turns out to be very convenient to put the entire service layer into it.
Examples:
github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Doctrine/UserManager.php
github.com/KnpLabs/KnpBundles/blob/master/src/Knp/Bundle/KnpBundlesBundle/Manager/BundleManager.php

Answer 2

Model in key MVC This is just a collective of business logic rather. In fact, in Symfony, all logic should be stored in services.
Entity is just like a data structure, it itself can also have logic, but minimally, since services are not available to it.
Model in the context of forms is something like Data transfer object, that is, an object that contains data in the desired format. In most cases, entities are the model for forms.
Controllers are just controllers, everything is covered pretty well in the documentation.
The logic, if for good, needs to be taken out to services. Almost everything can be moved from the controller to event listeners, separate utility services, form handlers (for deduplicating code in controllers, although it doesn’t often help). In a word, everything here very, very much depends on the project. But the entity should only store the data, and not change them in any way. You can only write additional getters that perform small data manipulations.

Answer 3

I use doctrine entities stuffed with business logic methods. If the business logic needs some entities that are not related to the current data schema, then I pass them as parameters to the methods, after pulling them out of the repositories in the controllers. The entities themselves do not know anything about storing them in repositories, ordinary POPOs, all storage logic is provided in the controller.
I use services when code duplication appears in the methods of various entities or it is simply not clear to which entity this or that method belongs - a typical example: transfer from account to account, both accounts are basically equal, and that the DebetTo method in the source, that the CreditFrom method in the recipient will be look ugly, especially if there is also a third account to which the commission for the transaction is transferred, and creating a transaction class in the model is impractical - a direct candidate for services. Generally services I consider as functions.

Answer 4

If the logic refers directly to the entity taken from the database, I push it into the Entity.
I don’t know how correct this approach is, because. I myself am still new to Symfony, but this solution seems quite logical to me.
As far as I understand, Models are rather used here to create abstract entities or interfaces, so that specific implementations can then be inherited from them, be it Doctrine or something else.

Answer 5

In this case, either like this, or as mentioned above, use the EntityManager (I would choose the 2nd in most cases, but it depends on the task anyway)