Doctrine ORM Best practices?

Question

PHP

Hello dear community!
This is not so much a specific question as a call to the collective mind. Many of you have worked with Doctrine ORM and written many great projects. And in the course of your work, you came across pitfalls, typical problems and solutions that you could perhaps share with others. For the sake of cleanliness and conciseness of the code, as well as architectural solutions that will speed up development, let's share our experience. You may have been able to create solutions that were successful (within the Doctrine ORM), perhaps there were those that drove you into a dead end.
On the Internet, you can find many best practices examples that work within the same entity, but are absolutely useless in real projects.
Let me give you a few examples:
It is good practice, in my opinion, to separate the repositories of the doctrine itself, and our repositories. To work inside your business logic, use your own repository classes / services, which you must implement from interfaces.
Take out the validation rules for entities, as well as the mapping, in separate YML files, and not in annotations. This is of course a moot point, which is convenient for anyone, but I prefer that my entities do not depend on the ORM.
Use flush with a parameter if you are going to perform an action only on a specific entity.
Do not be afraid of the constructor, write your entity dependencies in it, this will make the code safer and allow you to get rid of some setters.
Be careful about the new typing in php7 and interfaces, if you create an interface for an entity and write return types in it, as well as how you set scalar argument types, then after generating Proxy objects by the Doctrine, you will get an error about the class mismatch with the interface. (they say it will be fixed in version 2.6)

Answer 1

1. No setters. Entity must always be valid (setting values ​​via constructors, named constructors). If you need to change the state, we make meaningful methods, such as:
   

   public function updatePassword($plainPassword, EncoderInterface $encoder) {
       //...
   }
   public function updateProfile(UserProfile $profile) {
       //...
   }

   
   And many do not need dostrina, often enough active-records.
   Doctrine gives a big profit only if the domain logic is complex, well, all this fits well with model-driven design (DDD).

Answer 2

There is a very good presentation, take a look.
ocramius.github.io/doctrine-best-practices/#