Обходной путь наследования таблиц классов Doctrine 1.2?


хорошо, во-первых, я знаю, что это невозможно с 1.2., поэтому я ищу обходной путь.
И нет, к сожалению, я не могу использовать Doctrine 2, потому что мой сервер общего хостинга застрял на PHP 5.2.16, а администратор отказывается устанавливать поддержку PHP 5.3.

Итак, вот моя проблема, основная проблема родитель-потомок:
Допустим, у меня есть базовый класс User и дочерние классы Customer, Seller, Admin.

Я рассматривал методы наследования: простой (довольно бесполезный, IMO), конкретный и агрегация столбцов, и даже обходной путь для "фиктивное наследование таблицы классов" найдено здесь< /а>.

Что мне действительно нужно, так это «наследование таблиц классов», другими словами, User сопоставляется с отдельной таблицей, которая содержит все общие значения, а дочерние таблицы определяют сопоставление с отдельными таблицами, определяющими только их конкретные столбцы.

Я отказался от совершенства :) в PHP‹5.3 мне действительно все равно, как он будет храниться в базе данных, но моя объектная модель ДОЛЖНА иметь всю функциональность.

Итак, каков наилучший выбор для обходного пути?

Это то, что мне нужно.

  • Определение базового класса с общими значениями (имя, имя пользователя, пароль, адрес...)
  • Дочерние классы со всеми значениями (общими и их специфическими)
  • Дочерние классы должны видеть только свои переменные, а не из других дочерних классов (например, у Клиента не должно быть определено workingHours, которое является конкретным значением Продавца).
  • Я должен иметь возможность формировать отношения в базовом классе и в отдельных дочерних классах, и эти отношения должны быть привязаны к определенному классу (например, класс User должен иметь отношение к классу Address, класс Restourant должен иметь связь с классом Orders, Restourant также должен иметь определенную связь Address... но Admin не может иметь отношения Orders, потому что он не имеет ничего общего с заказами)

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

Надеюсь, вы поняли мой вопрос. Любые советы будут оценены, потому что я действительно не знаю, что делать здесь.


person ZolaKt    schedule 23.03.2011    source источник


Ответы (1)


У меня была такая же проблема несколько дней назад, и я выбрал наследование путем агрегации столбцов. Лежащая в основе концепция не является самым чистым или красивым решением из когда-либо придуманных, но делает свое дело и отвечает всем вашим требованиям, кроме одного:

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

Единственное, что здесь не работает, это то, что я выделил жирным шрифтом, но вы можете легко обойти это. Вы можете переопределить сеттеры и геттеры в своих дочерних классах, например, если кто-то попытается получить доступ или изменить поле в объекте Seller, принадлежащем Customer, вы не разрешаете это (выдаете исключение, возвращаете false и т. д.). .).

person Imi Borbas    schedule 23.03.2011
comment
Спасибо. Агрегирование столбцов (также известное как наследование одной таблицы) кажется единственным выходом. Я не сторонник компрометировать логику в деталях реализации, но я действительно думаю, что здесь нет другого выхода. - person ZolaKt; 24.03.2011