Jira issue originally created by user @beberlei:
There should be an interface composed of all the methods on the Repository, so that in userland you can do something like:
interface IMyRepository extends Doctrine\ORM\IEntityRepository
class MyRepository extends Doctrine\ORM\EntityRepository implements IMyRepository
That way in your code you could type-hint for IMyRepository, or for the EntityRepository Interface even and it would be indefinately easier to mock or replace the implementation.
Comment created by romanb:
To match our naming conventions that should rather be: interface EntityRepository and the old EntityRepository => BasicEntityRepository or similar.
Comment created by shurakai:
Roman, do you mean that we should rename the file (and class) EntityRepository to BasicEntityRepository and create a new EntityRepository that contains an interface EntityRepository?
If you want me to, I could do this.
@Christian: Yes, thats what I meant. I will schedule this for BETA3 though. I want BETA2 to be a smooth upgrade without any BC issues, if possible.
I am wondering whether this is really necessary? There are not many methods on EntityRepository and its easy to create your own interface(s) for your repositories that include these few methods. To be consistent with our naming standards there would have to be a bc break which seems unnecessary to me, unless we invent some other name for the interface, i.e. "ObjectRepository".
Comment created by @beberlei:
Issue was closed with resolution "Won't Fix"
Comment created by saem:
It's unfortunate this wasn't implemented, it's actually a significant issue for us. I have to say I completely disagree with Roman's reasoning in his last comment.
We have a very large database and commensurately many repositories. We're now at a point that we need to fire our own application level events (as an example, we end up having to compose in services a lot), some of them originating within repositories (doctrine events are insufficient, and we need application specific ones). We're using Symfony2 for DIC and build repositories not through doctrine but via services. We consider using setter injection to be a significant anti-pattern, an object should be valid/fully-initialized post construction so we'd rather not do that -- if you were wondering. Now for all our repositories that we would like to build in extra functionality we create our own repository class, compose in the doctrine repository and implement the interface by convention (we could write our own, but the mileage sucks). Now where we could have passed in an instance of anything obeying that interface we're stuck (there goes type hinting). We can avoid some drudgery through traits but it's still an unfortunate solution.
If this is at all possible (even if it has a less than ideal name), we'd very much appreciate this, thank you.
PS. A BC break in beta would have been very easy and now it sucks even more.
Comment created by @ocramius:
[~saem] there is such an interface in doctrine common. Check Doctrine\Common\Persistence\ObjectRepository at https://github.com/doctrine/common/blob/2.3.2/lib/Doctrine/Common/Persistence/ObjectRepository.php
Marco: I'm afraid that is incomplete. EntityRepository has a number of methods that fall outside of the scope of those prototyped in ObjectRepository and Selectable interfaces that it implements.
Why don't you ship your own layer of repositories and disregard the Doctrine ones completly? I do that all the time, and then constructor injection is very simple as well.
Because the repositories provide features we use. Reusing/staying close to Symfony/Doctrine makes it easier to learn/train, and gives us herd immunity benefits around shared knowledge and most importantly testing. We're trying to reduce maintenance burden, this interface would not only help us do that but anyone else in a similar situation. Additionally, we have many projects most of them large, going across them we've got something like 400+ tables.
[~saem] your last comment does not really provide any rationale behind extraction of the remaining methods into an interface. There's no advantage in extracting those methods to an own interface. createQueryBuilder, createResultSetMappingBuilder, createNamedQuery, createNativeNamedQuery, clear, **call, getEntityManager, getClassMetadata are all utility methods that are not good candidates for an interface. You can easily re-implement those on an existing entity manager.
Just use the Doctrine\Common\Persistence\ObjectRepository API: you should actually stick to that to increase portability across the various object managers in doctrine project.
If you need all those methods too, you are looking for inheritance, not composition (and probably are delegating too much responsibility to the repository).
Marco, rather than looking at each comment in isolation (which is what seems to be happening), please take things in aggregate. I've provided the rationale in previous comments. If you require more information I can clarify further.
Extracting as an interface would: