Объекты обслуживания с Doctrine2 и Symfony2 - PullRequest
3 голосов
/ 06 октября 2011

Я работаю над проектом Symfony2 / Doctrine2, который обрабатывает 2 базы данных на MSSqlServer.

Первая база данных A_db имеет таблицу форм , а вторая B_db имеет людей . Все мои объекты определены с аннотациями.

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

Я потратил некоторое время на чтение связанных вопросов:

Поэтому я решил, что услуга может быть лучшим способом удовлетворения моих потребностей. Но мне не ясно, как на самом деле это сделать. Я имею в виду, где разместить мой класс обслуживания, как определить его в config.yml, как в people entity ...

Мое желание состоит в том, чтобы настроить полный сервис (при условии, что это лучшая реализация) для выполнения чего-то вроде:

foreach($onePeple->getForms() as $form) {/* some code with form */}

Если внедрение службы для доктрины не является наилучшей практикой, то что бы это было и как я могу заставить ее работать?

1 Ответ

0 голосов
/ 06 октября 2011

То, что вы спрашиваете, возможно, используя одни только сущности - до тех пор, пока вы определяете такие отношения в сущности формы:

/**
 * @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, поэтому, если вы этого хотите, это может быть лучшим решением. Мы стремились использовать сервисы, так как они тогда просто связаны с реализацией бизнес-правил и т. Д., Оставляя репозитории для использования в качестве компонента постоянного уровня.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...