Doctrine Repositories best practice

[webdevilopers]

For naming conventions please see:

• Naming Conventions Repositories dddshelf/ddd-in-php-book-issues#51

Injecting EntityManager only and the Law of Demeter:

• https://github.com/dddinphp/repository-examples/blob/master/src/Infrastructure/Persistence/Doctrine/DoctrinePostRepository.php#L12-17
• https://disqus.com/home/discussion/adamquaile/composition_over_inheritance_in_doctrine_repositories_72/#comment-2703359347 @adamquaile

Extend the Doctrine EntityRepository as suggested by @MacDada?

• https://gist.github.com/MacDada/025ef645837363fef0ec1ea0a2ead6fb
• http://disq.us/9sm2jy

Blending ORM and ODM:

• Blending ORM and ODM but keeping the Domain Model clean #2

[webdevilopers]

On extending the EntityRepository: I've seen several examples inside the @dddinphp PHP in DDD book doing it:

class DoctrineOrderRepository
    extends EntityRepository
    implements OrderRepository

I guess this is a matter of taste similar to using ArrayCollection in your Domain Models:

• http://stackoverflow.com/a/18474456/1937050 @koryonik
• http://stackoverflow.com/a/29552486/1937050 @dermo666

[MacDada]

I guess this is a matter of taste similar to using ArrayCollection in your Domain Models

BTW, I try to avoid ArrayCollection in accesors' phpdocs.

class Foo
{
    /**
     * @var ArrayCollection|Bar[]
     */
    private $bars;

    /**
     * @return ArrayCollection|Bar[]
     */
    public function getBars()
    {
        return $this->bars;
    }
}

/\ That way any object could modify my $bars collection outside Foo. For example, this is possible:

$foo->getBars()->add('haha, not a Bar');

That's why I limit phpdoc for getBars() to just Bar[]:

class Foo
{
    /**
     * @var ArrayCollection|Bar[]
     */
    private $bars;

    /**
     * @return Bar[]
     */
    public function getBars()
    {
        return $this->bars;
    }

    public function addBar(Bar $bar)
    {
        $this->bars->add($bar);
    }
}

Now the devs are "forced" to use addBar() method which will guard for only Bar elements in the collection.

It is still technically possible to modify $bars from the outside, as the returned stuff is actually an ArrayCollection for PHP. But it's not for developers. Developers won't know that (shouldn't know, shouldn't care) and are forced to treat it as array.

Well, not exactly array, as they cannot do array_map() for example. But they can do foreach or [2].

If I want to give more power "for the outside", I would do Bar[]|Traversable|Selectable, etc.

But I usually want to encapsulate any stuff related to $bars collection inside Foo.

[webdevilopers]

A nice compromise on Naming Conventions by @theUniC:

I think that naming them DoctrineORMFooRepository or DoctrineODMBarRepository it's a pretty simple and good solution.

But I guess I will go for:

• Acme\Infrastructure\Persistence\Doctrine\MysqlFooRepository
• Acme\Infrastructure\Persistence\Doctrine\MongoFooRepository

[MacDada]

Acme\Infrastructure\Persistence\Doctrine\MysqlFooRepository

@webdevilopers That's a bad name. U can switch Mysql to Progress in one minute when using Doctrine ORM/DBAL. It's a matter of configuration. Doctrine gives u abstraction over SQL databases – unless u use "native queries", your repo won't change when u change the DB vendor.

Acme\Infrastructure\Persistence\Doctrine\SqlFooRepository
Acme\Infrastructure\Persistence\Doctrine\DbalFooRepository
Acme\Infrastructure\Persistence\Doctrine\OrmFooRepository

Would be better.

[sstok]

Concerning the Collection problem, you could return a wrapped/decorated Collection that only allows getting but not modifying. Internally you still have the actual mutable Collection 👍

Whenever a getter method is called you forward to the internal collection, but when someone tries to call remove() they get an exception.

[webdevilopers]

Some more notes on extending repositories:

Some of the @dddinphp book examples show the minimum implementation for EntityRepository using a custom constructor:

class DoctrinePostRepository implements PostRepository
{
    protected $em;

    public function __construct(EntityManager $em)
    {
        $this->em = $em;
    }

• https://github.com/dddinphp/repository-examples/blob/master/src/Infrastructure/Persistence/Doctrine/DoctrinePostRepository.php#L10-L17

Personally I prefer extending the @doctrine EntityRepository - an approach which is shown in some @dddinphp examples later too:

class DoctrineOrderRepository
    extends EntityRepository
    implements OrderRepository

Any reasons why the second implementation is mentioned only later in the @dddinphp book @carlosbuenosvinos ?

In order to make the second solution work in @symfony using the getRepository method you have to define your custom repository e.g. via annotations:

/**
 * @ORM\Entity(repositoryClass="Acme\Infrastructure\Persistence\Doctrine\OrderRepository")
 */

In order to use these repositories in your services you should create a service in order to inject them.

The ODM version looks similiar:

/**
 * @MongoDB\Document(repositoryClass="Acme\Infrastructure\Persistence\Doctrine\OrderRepository")
 */

The service:

order.repository:
    class: Acme\Infrastructure\Persistence\Doctrine\OrderRepository
    factory_service: doctrine_mongodb.odm.document_manager
    factory_method:  getRepository
    arguments: ["Acme\AppBundle\Document\Order"]

As answered by @ahmedmhmd here:

• http://stackoverflow.com/questions/22627631/unable-to-use-repository-class-in-symfony2-with-mongodb

Related issues:

• XML mapping for Doctrine MongoDB ODM References Extension #9
• Blending ORM and ODM but keeping the Domain Model clean #2

[webdevilopers]

After a lot of research - thanks for everybody involved here - I started my first blog post about my experiences with this topic:

• http://blog.webdevilopers.net/domain-driven-design-repositories-with-doctrine-orm-and-odm-in-symfony/

[webdevilopers]

Some related posts:

• http://wouterj.nl/2016/12/repositories-are-just-collections/ by @wouterj
• https://stovepipe.systems/post/service-decoration-in-practice by @yannickl88

@kbond

[deeky666]

Being a member of the Doctrine team I would like to add my 2 cents on this topic.

Personally I don't like very much the bloated API that Doctrine repositories expose. IIRC we had some discussions about that and a general consensus about that was that we would not implement it like this again. It is too much of a facade to the entity manager.

My personal opinion is that the repository should basically really only behave like a collection as Martin Fowler describes and limit its responsibilities to being a thin layer to the data mapper / storage. If we had generics in PHP, I would even define a generic repository interface like for a general collection or map interface. Methods like save() / persist() / insert() / update(), flush(), createQuery() should not be part of a repository as those are too specific for databases. Instead one should use term like add, filter, reduce, retain etc. like in a regular collection.

This is also the reason why I don't extend the Doctrine repository in my projects but define my own thin interfaces instead and simply inject the entity manager.

Just my opinion, though...

[webdevilopers]

Thanks for your thoughts @deeky666 . I get your point!

I guess the same is true for the @hibernate API since @doctrine was inspired by it?

The examples in my blog indeed take full "advantage" of what Doctrine "offers". Guess my future implementations will look similar to your suggestions too.

Would like to hear what @Ocramius thinks about this too!

[ScreamingDev]

Just found this. Cool! I have some neat thoughts to share too.
Queries have been an issue to me. On the one side building those in controller would be very flexible
but on the other hand the majority of developer would vasectomize me for that.
So I used DDD itself to build simple "queries" like this:

abstract class AbstractRepository implements RepositoryInterface
{
protected function createQueryBuilder($amount = null, $start = null, $order = [])
    {
        $qb = $this->repository->createQueryBuilder('e');

        if ($amount) {
            $qb->setMaxResults($amount);
        }

        if ($start) {
            $qb->setFirstResult($start);
        }

        foreach ($order as $field => $direction) {
            $qb->orderBy($field, $direction);
        }

        return $qb;
    }

    public function findAllSimilar($entity, $amount = null, $start = null, $order = [])
    {
        $qb = $this->createQueryBuilder($amount, $start, $order);

        $this->parseQuery($entity, $qb);
    }

    abstract protected function parseQuery($entity, $queryBuilder);
}

First of all: This is done using the query builder because the Doctrine Paginator likes it.
With this you can fill an entity with some information and use it as a filter:

$human = new Human();
$human->setGender('yes');
$human->setColor('#ABC');
$human->setOccupation('dev');

$others = $repo->findSimilar($human);

This should explain it already. In the concrete repo the ::parseQuery method is implemented:

class HumanRepo extends AbstractRepository {
    protectec function parseQuery($human, $queryBuilder) {
      if ($human->getGender()) {
        $queryBuilder->andWhere($queryBuilder->expr()->eq('e.gender', $human->getGender()));
      }

      // and so on
    }
}

This made prototyping very easy and gave the controller some flexibility.