Use EntityManagerInterface in type declarations

[derrabus]

The codebase inconsitently switched between EntityManagerInterface and EntityManager in type declarations. This will get us into trouble if we want to migrate to native type declarations on 3.0.

This PR switches all type declarations to EntityManagerInterface where possible.

[greg0ire]

I think @beberlei had a plan to kill that interface, not sure if this is the right move but I think he needs to review this.

[derrabus]

@beberlei Do you have input on that topic?

[beberlei]

We introduced the interface to help with the use of EntityManagerDecorator, since we didn't want people to extend the EntityManager and its marked as "soft final".

The problem is in a decoration, code like new UnitOfWork($this) or $this->repositoryFactory->getRepository($this, $entityName); does not pass the decorator, but the decoratee / original.

Its a hard problem, it seems some people want to extend/decorate the EM for whatever reason, but its not a good solution for us. We could just give up and recommend extending EntityManager instead to simplify the problem for us. A lot of time has been wasted into this interface already.

[derrabus]

So your plan would be to get rid of the interface (and consequently the abstract decorator) completely? That would generate the harder migration path for applications. Especially in Symfony applications, it is common to type-hint EntityManagerInterface if write a service that depends on the entity manager. Also, the interface is quite handy if you want to write mock implementations of the EM.

I agree that decorating the entity manager is not really a good way of extending the ORM. But at this point, I'd keep the interface tbh.

[beberlei]

Probably a wishful thinking of me, but yeah it would have been nice. But you are right, we should just go with the interface now. 👍 from me then. One question, i would remove the trait and inline the code into AbstractIdGenerator, unless I am not seeing something.