Как я могу сделать сложные запросы ассоциаций сущностей в доктрине 2?(виртуальная сущность)

Question

Допустим, у меня есть приложение для блога.
Автор может добавить к сообщению несколько изображений, указав ссылку на URL существующего изображения в Интернете, или загрузить новое изображение.

Я хочу иметь возможность вернуться назад с изображения (загруженного или URL-адреса) ко всем публикациям, использующим это изображение, и из определенного сообщения ко всем изображениям в этом сообщении (например, чтобы я мог удалить изображения являются незаконными и / или приостанавливают публикацию, в которой они используются, до тех пор, пока автор не исправит сообщение).

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

В результате получается более сложный код, так как при каждом сохранении отредактированного сообщения мне нужно проверять, какой тип является конкретным изображением (из всех изображений в сообщении, которое мне нужно просмотреть), а затем создавать или обновлять его. Записать и присвоить полю отношения в объекте post.

Итак ... предполагая, что у меня есть сущности UploadedImage и UrlImage, я подумал о наличии метода setImages в сущности post, который проверяет каждое полученное изображение, загружено ли оно или URL , а затем вызывает либо setUploadedImages, либо setUrlImages.

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

Звучит немного сложно, и я удивился:

1. Как я могу иметь виртуальную сущность доктрины (с ее хранилищем и всем)?
2. Есть ли лучший дизайн для него?

Answer 1

Вот документация о том, что вы пытаетесь сделать:
http://doctrine -orm.readthedocs.org / en / latest / reference / inheritance-mapping.html

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

Если (код) пользователи этих изображений обрабатывают их одинаково, независимо от их происхождения, добавленная сложность запроса и использование базы данных будутне стоит нормализации.