Доктрина — сделать несколько сущностей из одной таблицы
В настоящее время я работаю над огромный Рефакторинг проекта. Мы взяли на себя классический проект PHP / MySQL, в котором большая часть кода является процедурной, продублированной, и в ней очень мало намеков на архитектуру.
Я планирую использовать Doctrine для обработки нашего доступа к данным, и все мои таблицы будут сопоставлены с сущностями. тем не мение, наши таблицы MySQL в значительной степени испорчены.
Таблица, с которой я сейчас работаю, содержит более 40 столбцов и не нормализуется никакими средствами. Быстрый пример того, что мы имеем:
марка
id
name
poNumber
orderConfirmationEmail <---- these should go into a BrandConfirmations entity
shippingConfirmationEmail <-----
bill_address <---- these should go into a BrandAddress entity
bill_address2 <-----
city <------
.
.
.
В идеале, я хотел бы, чтобы Doctrine вытащил поля, которые ссылаются на разные сущности, и фактически поместил их в эти сущности. Так, например, id, name и poNumber будут извлечены в марка юридическое лицо. orderConfirmationEmail и shippingConfirmationEmail будут извлечены в сущность BrandNotification. Затем bill_address и остальные поля адреса будут извлечены в сущность BrandBillAddress. Есть ли способ настроить Doctrine для разбиения таблицы на эти модели для меня, или я должен сам написать собственный код, который бы это делал?
Если мне действительно нужно написать код для разделения этой таблицы самостоятельно, есть ли у вас какие-либо ресурсы или советы, которые помогут решить аналогичную проблему? Я еще не смог найти много.
Решение
Последняя версия Doctrine 2 поддерживает то, что они называют встраиваемыми: http://doctrine-orm.readthedocs.org/en/latest/tutorials/embeddables.html. Это может решить некоторые ваши проблемы. Однако для этого требуется D2.5 +. В настоящее время S2 использует Doctrine 2.4. Вы можете поэкспериментировать с использованием самой последней доктрины.
Что вы можете сделать, так это заставить ваши доменные модели (сущности) действовать так, как если бы у вас были объекты значения. Таким образом, $ brand-> getOrderConfirmation () фактически возвращает объект подтверждения заказа. Вы должны поэкспериментировать, чтобы все было сопоставлено с одной таблицей, и вы можете быть ограничены в некоторых своих запросах, но это не так сложно. Преимущество в том, что остальные ваши новые приложения имеют дело с правильными нормализованными объектами. Это только внутренний код персистентности, который должен запутаться.
Есть довольно много ссылок на этот подход. Вот один из них: http://russellscottwalker.blogspot.com/2013/11/entities-vs-value-objects-and-doctrine-2.html
Лучше всего, конечно, реорганизовать схему базы данных. Мне нравится делать вид сырого дампа исходной базы данных в файл yaml с желаемым вложением объекта. Затем я загружаю файл yaml в новую схему. Если вам действительно повезет, вы даже сможете создать новые представления для существующего приложения, которые позволят ему продолжать работать параллельно с вашим новым приложением.
Другие решения
Других решений пока нет …