То, что вы спрашиваете, возможно, используя одни только сущности - до тех пор, пока вы определяете такие отношения в сущности формы:
/**
* @OneToMany(targetEntity="Form", mappedBy="User")
*/
protected $Forms;
А на сущности пользователя:
/**
* @ManyToOne(targetEntity="User", inversedBy="Forms")
*/
protected $User;
Затем вы можете просто загрузить сущность пользователя (через службу, репозиторий или по своему усмотрению), а затем получить доступ ко всем формам, принадлежащим этому пользователю, через $userObj->Forms
(если вы используете magic __get на ваших сущностях, если не используете затем метод получения, опять же по вашему усмотрению). Forms
- это экземпляр объекта, реализующего интерфейс Doctrine\Common\Collections\Collection
(поскольку это отношение ко многим), который можно повторять, используя foreach.
В проектах, над которыми я работал с Doctrine2, мы обычно используем наши сервисы для получения, сохранения и удаления сущностей, а также перечисляем сущности типа (мы называем их индексными методами). Таким образом, вы можете связать дополнительные функции, необходимые для сохранения, такие как обновление других объектов, которые тесно связаны, и так далее. Эти сервисы привязаны к постоянному уровню и содержат ссылку на менеджера сущностей, оставляя сами сущности изолированными и тестируемыми.
У нас также был аргумент о том, использовать ли такую логику в репозиториях или сервисах, но это скорее случай личных предпочтений и / или требований проекта.
Стоит отметить, что создаваемые вами сервисы не будут связаны с Doctrine. Он не знает о вашем уровне обслуживания (это всего лишь некоторый код пользовательского интерфейса), поэтому вы можете связать его осмысленно и четко. По сути, вам нужно что-то, где вы могли бы передавать диспетчер сущностей через конструктор службы и иметь некоторый базовый класс службы, способный работать со всеми сущностями, который затем можно было бы расширить с помощью специальной логики для каждой сущности. Однако хранилища неразрывно связаны с Doctrine, поэтому, если вы этого хотите, это может быть лучшим решением. Мы стремились использовать сервисы, так как они тогда просто связаны с реализацией бизнес-правил и т. Д., Оставляя репозитории для использования в качестве компонента постоянного уровня.