Уменьшить связь в сущностях

Question

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

Каждый экземпляр сущности Message долженУ меня есть отправитель и получатель, instanceof Symfony\Component\Security\Core\User\UserInterface, который мне может потребоваться просто в установщиках для свойств.Однако при настройке отношений ORM кажется, что мне нужно специально установить targetEntity (например, Foo\BarBundle\Entity\User), что означает, что для дальнейшего использования объекта Message в разных приложениях потребуется либо изменение кода, либо чисткаони используют сущность User, которая, как мне кажется, не входит в сферу действия пакета обмена сообщениями.

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

РЕДАКТИРОВАТЬ: Я попытался установить глобальный параметр с расширением и использовать его в аннотациях, что-то вроде @ORM\ManyToOne(targetEntity="%my.entity%"), но кажется, что анализатор аннотаций не преобразует параметры, потому что строка интерпретировалась какбуквальный, который потерпел неудачу, конечно.

Answer 1

Решением, на котором я наконец остановился, было создание MessengerIdentity, хранящегося в базе данных, который принимает объект и сохраняет его имя класса и идентификатор. Затем я использовал LifecycleEvent для загрузки ссылки на сущность, хранящуюся в MessengerIdentity, так что что-то вроде $messenger->getSender()->getUsername все еще возможно.

Вы можете увидеть мою реализацию на github (в частности, entity и обработчик событий Doctrine ) ... вы также можете увидеть обсуждение от группа пользователей doctrine2 здесь .

РЕДАКТИРОВАТЬ: После дальнейших размышлений я решил, что мне не нравится реализация, о которой я говорю выше (во-первых, я, по сути, копировал код в другие проекты, что было очень загромождено). и в нарушение DRY), и поэтому я реорганизовал свой код так, чтобы сущность Message была абстрактным отображенным суперклассом с абстрактными методами, которые понадобятся бизнес-логике, ссылаясь на отправителя и получателя.

Теперь конечный разработчик должен создать окончательную реализацию сущности Message, а базовый класс даже не касается реализаций для отправителя и получателя, что позволило достичь желаемого результата, заключающегося в уменьшении зависимости пакета от конкретного класс пользователя.

Answer 2

Вы можете создать объект Model со всей бизнес-логикой, а затем создать Entity, который расширяет модель, но добавляет к ней код менеджера сущностей и аннотации доктрины. Вот как работает FOSUserBundle.