2016-04-22 2 views
1

Я столкнулся с двумя способами, чтобы вводить зависимости в пользовательские репозитории Doctrine.Инъекция зависимостей в пользовательском репозитории Doctrine

  1. https://juriansluiman.nl/article/142/dependency-injection-in-a-doctrine-repository
  2. http://blog.tomhanderson.com/2016/01/dependency-injection-in-doctrine.html

Я понимаю, метод один в том, что он больше не использует диспетчер объектов для извлечения хранилища и вместо этого использует менеджер службы.

Однако, я не понимаю метод два. Есть две части, которые я не понимаю. Первый - это раздел «Конфигурация». Что делает ключ конфигурации «Doposrine» «repository_factory»?

return array(
    'doctrine' => array(
     'configuration' => array(
      'orm_default' => array(
       'repository_factory' => 'Db\Repository\RepositoryFactory', 
      ), 
     ), 
    ), 

    'service_manager' => array(
     'invokables' => array(
      'Db\Repository\RepositoryFactory' => 'Db\Repository\RepositoryFactory', 
     ), 
    ), 
); 

Затем, во-вторых, я не уверен, как получить репозиторий. Должен ли я использовать диспетчер объектов? Или я должен использовать диспетчер служб, как и в первом методе?

ответ

1

Насколько я понимаю, вторая ссылка дает возможность переопределить аргументы по умолчанию, переданные в репозиторий при его создании.

Основная роль фабрики (а не только в Symfony, это общий design pattern) - создавать экземпляры одного или нескольких классов, а не создавать их самостоятельно с помощью ключевого слова new.

При вызове $em->getRepository('EntityFQCN'), Doctrine (через repository_factory) ищет возможный Repository класс, определенный в вашей Сущности (т.е. @ORM\RepositoryClass(...)) и возвращает экземпляр этого, в противном случае, если нет Repository класса найден для объекта, его возвращает экземпляр по умолчанию EntityRepository, с указанным объектом в качестве аргумента (то есть getRepository('EntityFQCN')).

Итак, не глядя на ссылку в деталях, я могу сказать, что если вы попытаетесь реализовать эту альтернативу, вы получите свой репозиторий через «по умолчанию» способ, то есть EntityManager::getRepository('xxxx').
Роль этой части конфигурации будет заключаться в том, чтобы создать экземпляр репозитория иначе, чем по умолчанию.

Я уже переопределял RepositoryFactory, когда мне нужно было переопределить значение по умолчанию EntityRepository (вернуть экземпляр настраиваемого класса репозитория, не определяя его в моих сущностях, другими словами, заменить класс репозитория по умолчанию). Вы можете see it in action.

Надеюсь, вам очень понравится DI в Доктрине.

+0

Таким образом, я предполагаю, что для каждого возможного репозитория я хотел бы добавить зависимости в я бы нуждался в аналогичном условии 'if (is_subclass_of ($ entityNamespace, '\ App \ Util \ Doctrine \ Entity \ EntityInterface', true)) {'в этом единственном файле. Я также должен был бы иметь все мои операторы 'use' в одном файле для каждого репозитория, в который я хочу вложить зависимости. Я считаю, что было бы более модульным использовать первый метод. Есть ли причина использовать один метод над другим? Или это просто предпочтение? –

Смежные вопросы