Use Repository managed by Doctrine automatically

[loic425]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Related tickets
License	MIT

• Attaching the Persist & Delete processors automatically via the ManagerRegistry
• Deprecating driver configuration in ResourceMetadata
• Deprecating driver configuration in Bundle configuration (should be done when all the new routing system will be available in Sylius E-commerce)

The Persist & Remove processors already use the Repository managed by Doctrine.
But the system was using a driver detection using the config (by default, a resource is configured with 'doctrine/orm' as driver).

At the end, we'll be able to use the Resource without any driver configuration. You can look at the current DoctrineOrmDriver to see how much the complexity is.

With this new system, if you use a Repository managed by Doctrine, it will be used automatically, otherwise, you are able to use custom providers which are more powerful (retrieve sth from anywhere you want).

Moreover, the driver system has some issues with the repository (see #981)
So it's hard to maintain & trust the Sylius Repository configuration system.
Indeed, the repository to be used by Doctrine is configured on Runtime.

We have this System in ApiPlatform
https://github.com/api-platform/core/blob/main/src/Doctrine/Orm/Metadata/Resource/DoctrineOrmResourceCollectionMetadataFactory.php

More explanation about driver false

Setting driver to false already exists, it disables the driver system. It was introduced to detach a resource from Doctrine when the resource was not an entity.
In this case, there's no built-in factory & repository.

About repository DI

with current implementation, RepositoryInterface was generic and that's why it was introduced a binding via the repository name which is not well-known and not documented.

class Test 
{
    public function __construct(
        private RepositoryInterface $bookRepository, // It injects 'app.repository.book'
    ) {}
}

In Symfony, by default, when we use the Entity maker command, we also have a service entity repository which is automatically created.

namespace App\Repository;

use App\Entity\Book;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;

class BookRepository extends ServiceEntityRepository
{
    public function __construct(ManagerRegistry $registry)
    {
        parent::__construct($registry, Book::class);
    }
}

Cause this is a service, it could be injected directly or with an interface. This is the normal way to inject services in Symfony.

use App\Repository\BookRepository;
use App\Repository\BookRepositoryInterface;

class Test 
{
    public function __construct(
        private BookRepository $bookRepository,
        // Or private BookRepositoryInterface $bookRepository,
    ) {}
}

In Sylius E-commerce, we still need to create this "sylius.repository.order" but we'll need to declare these services manually instead as we do for every services.

If you have a generic EntityRepository, it's still possible to configure a binding with name via Symfony DI configuration.
It could be automatic, this "automation" already exists in this package and could be moved to Sylius E-commerce where the repository will be created with an app.repository.book id.

# config/services.yaml
services:
    _defaults:
        bind: 
            EntityRepository $bookRepository: '@app.repository.book'

RepositoryInterface is already optional

Implementing this interface is already optional since this new resource metadata implementation.
The Persist and Remove processors retrieve the repository managed by Doctrine.
So this PR just use the same solution with providers.

[loic425]

We do not use this repository by default anymore.

[loic425]

This Provider was kind of Doctrine related, we use another improved one which is configured if the Resource is managed by Doctrine only.

[loic425]

I've removed this default provider which was a lot related to Doctrine.

[loic425]

We can still use a factory service here but the app.factory.subscription doesn't exist if we do not configure any driver.
So It's more complicated like this, cause we need to tag this factory to be used in the repository locator.

[loic425]

Hopefully, this provider is experimental, so we could move it and improve it.

[NoResponseMate]

Suggested change

	<service id="sylius.doctrine_orm.metadata.resource.metadata_collection_factory"
	<service id="sylius.resource_metadata_collection.factory.doctrine.orm"

Would make it easier to find since it'd be in line with the decorated service

[NoResponseMate]

Suggested change

	<service id="sylius.state_provider.doctrine.orm.state.provider" class="Sylius\Resource\Doctrine\ORM\State\Provider">
	<service id="sylius.state_provider.doctrine.orm" class="Sylius\Resource\Doctrine\ORM\State\Provider">

Seems a bit superfluous

[NoResponseMate]

Suggested change

	/** @var ResourceMetadata $resource */
	foreach ($resourceCollectionMetadata->getIterator() as $i => $resource) {
	foreach ($resourceCollectionMetadata->getIterator() as $i => $resource) {

Setting phpstan params (TKey, TValue) on ResourceMetadataCollection would ease type-hinting

[NoResponseMate]

Maybe put it in a const, or pass through the constructor as a parameter?