Лучшие практики / информация: Написание PHP4 ORM

Question

По ряду причин (все из которых, в основном, могут быть разбиты на неверные управленческие решения), мы не можем перейти на PHP5, то есть нам придется поддерживать PHP4, вероятно, еще несколько лет.

Поскольку многие наши приложения (как и многие веб-приложения) являются прославленными CRUD-приложениями, и поскольку мне нравится подбирать случайный домашний проект, чтобы тратить время на него, я сейчас пишу небольшой ORM-подобный класс, который будет служить оболочкой для большинства базовых запросов (среди прочего, вставка, обновление, замена, удаление). Поскольку он должен поддерживать PHP4, о PDO не может быть и речи, поэтому мне придется вернуться к языку -специфичные функции, такие как mysql_query. Поскольку мы используем несколько разных систем, в разных версиях (Interbase версии 4 и выше, Firebird, MySQL), мой класс ORM / Wrapper (не уверен, как его назвать) неизбежно станет большим.

Чтобы решить эту проблему, я подумал о двух возможных «решениях»:

• Напишите один массивный класс с switch операторами внутри функций на основе переменной $database_system, которая определяет используемый язык / СУБД
• Написать один базовый класс и написать один производный класс для каждой СУБД (возможно, для версии, если функции сильно различаются между ними). ​​

В настоящее время я склоняюсь ко второму варианту; На мой взгляд, это облегчает обслуживание, особенно при добавлении новой СУБД в список поддерживаемых. С другой стороны, с каждой СУБД, использующей свой собственный набор функций PHP, я не уверен, сколько будет наследоваться от базового класса. Помня, что этот класс в конечном итоге будет поддерживать такие функции, как организация очередей, выполнение (и, возможно, фиксация, если поддерживается) всего списка запросов одновременно.

Учитывая эту ситуацию, какой подход будет наилучшим? A или B, или, возможно, есть C, который я еще не рассматривал? Некоторые примеры существующих классов были бы идеальными, к сожалению, большинство ORM, с которыми мне приходилось сталкиваться, полагаются на (только PHP5) PDO класс.

Answer 1

Обязательно используйте ваш вариант 2. Ваш ОО-подход превосходит массивный оператор switch. Ваш базовый класс даст вам больше, чем просто наследование общих методов. Он дает вам непротиворечивый интерфейс, который впоследствии можно будет использовать в качестве адаптера при переходе на другую стратегию сохранения базы данных (PHP5 / PDO, когда управление приходит в себя?). Я бы даже тщательно смоделировал ваш интерфейс после PDO до такой степени, что PDO может даже стать заменой для вашего собственного уровня персистентности, если это необходимо. Кроме того, кривая обучения для новых разработчиков проекта, изучающих ваш уровень персистентности, будет ниже, если они уже имеют опыт работы с PDO.

Answer 2

Если кто-то ищет что-то похожее (я не надеюсь на это), но если - вы должны взглянуть на xPDO.

Это альтернатива для pdo, работающего над php4. Никогда не пытался использовать это - но я думаю, что это должно работать ... http://www.xpdo.org/

Answer 3

Я не могу понять управленческое решение использовать абсолютно неподдерживаемое программное обеспечение в качестве основы для разработки нового программного обеспечения. Для менеджера существуют практически нулевые затраты на установку PHP 5 хотя бы параллельно. Единственным следствием PHP 4 являются более высокие затраты на разработку (имеется больше классов PHP 5, чем для PHP 4, в настоящее время все инструменты в основном зависят от PHP 5, а последние напоминания о PHP 4 исчезают), а производство с PHP 5 обходится дешевле - самостоятельно исправлять ошибки во время выполнения PHP, PHP 5.3 использует намного меньше системных ресурсов, ....)

Но если вы действительно хотите пойти по этому пути: Pear :: MDB2 должен делать то, что вам нужно, и он совместим с PHP 4 и очень стабилен.

Но я бы предпочел сменить работу ... такие решения обычно не единственные глупые.