собственный ORM: записи базы данных в случае JOIN? - PullRequest
0 голосов
/ 26 сентября 2011

Мы делаем нашу собственную платформу с возможностью ORM. Таблицы базы данных теперь являются классами, но как насчет записей? Давайте представим две таблицы:

Users
ID,USERNAME

Emails
USER_ID,ADDRESS

Итак, у объекта записи будут методы getID (), getUSERNAME () и т. Д., Но если две таблицы являются JOIN-ed, у него не может быть двух типов, верно? Так как нет множественного наследования. А как насчет столкновения поля?

Ответы [ 3 ]

0 голосов
/ 26 сентября 2011

DBIx :: Class обрабатывает это, имея класс для каждой таблицы, а объединения представлены методом, который получает объект, соответствующий другой таблице.

$myAddress = $myUser->emails->address;
0 голосов
/ 26 сентября 2011

Я предоставляю некоторые сведения, основанные на реализации Model / ORM этой PHP UI Framework . Вот несколько советов от меня:

  • Не решайте слепо отображать функции в поля. Почему бы не использовать get ('field') и set ('field'). Недостатков нет (если не считать намеков на IDE), но вы можете избежать генерации кода или всеохватывающего подхода, который обычно медленнее.
  • При присоединении вы не обязательно захотите несколько объектов. В моем ORM одна Модель может работать с объединенными таблицами. Это обеспечивает прозрачность, и когда вы вызываете $ model-> set ('address'), это может быть связано с объединенной таблицей. Я все еще использую подэкземпляр динамического запроса для подвыборов, но для объединений в этом нет необходимости.
  • Я вижу много возможностей наследования и способности изменять форму родительских моделей в родительской модели. В каждой таблице может быть несколько моделей, в зависимости от того, как ваша компания использует .
  • Модели и ORM должны быть разделены, но должны очень тесно взаимодействовать. Мне также удалось заставить все играть хорошо с универсальными представлениями и универсальными контроллерами, что значительно экономит время.

Надеюсь, это поможет найти свой собственный путь или принять решение о том, чтобы не внедрять свой собственный ORM. Это не простая задача.

0 голосов
/ 26 сентября 2011

Я думаю, что каждый класс должен представлять запись, а вся таблица должна быть массивом (или некоторой другой коллекцией) объектов.Взгляните на http://www.doctrine -project.org / , чтобы получить некоторые идеи.

А для JOIN у вас должен быть какой-то механизм определения псевдонимов.Таким образом, вы можете справиться со столкновением полей.

А для геттеров и сеттеров вы можете использовать __call, __get и __set.См. http://php.net/manual/en/language.oop5.overloading.php для получения дополнительной информации.

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