Лучшие практики / информация: Написание PHP4 ORM
По ряду причин (все из которых, в основном, могут быть разбиты на неправильные управленческие решения), мы не можем перейти на PHP5, то есть нам придется поддерживать PHP4, вероятно, еще несколько лет.
Поскольку многие наши приложения (как и многие веб-приложения) являются прославленными CRUD-приложениями, и поскольку мне нравится подбирать случайный домашний проект, чтобы тратить время на него, я сейчас пишу небольшой ORM-подобный класс, который будет служить оберткой для большинства основных запросов (среди прочего, вставить, обновить, заменить, удалить). Поскольку он должен поддерживать PHP4, PDO не может быть и речи, поэтому мне придется вернуться к специфическим для языка функциям, таким как mysql_query, Поскольку мы используем несколько разных систем, в разных версиях (Interbase версии 4 и выше, Firebird, MySQL) мой класс ORM / Wrapper (не знаю, как его назвать) неизбежно станет большим.
Чтобы решить эту проблему, я подумал о двух возможных "решениях":
- Написать один массивный класс, с
switchзаявления внутри функций, основанных на$database_systemпеременная, которая определяет используемый язык / РСУБД - Напишите один базовый класс и один производный класс для каждой СУБД (возможно, для каждой версии, если функции сильно различаются между ними).
В настоящее время я склоняюсь ко второму варианту; На мой взгляд, это облегчает обслуживание, особенно при добавлении новой СУБД в список поддерживаемых. С другой стороны, с каждой СУБД, использующей свой собственный набор функций PHP, я не уверен, сколько будет наследоваться от базового класса. Помня, что этот класс в конечном итоге будет поддерживать такие функции, как организация очередей, выполнение (и, возможно, фиксация, если поддерживается) всего списка запросов одновременно.
Учитывая эту ситуацию, какой подход будет лучшим? A или B, или, возможно, есть C, который я еще не рассматривал? Некоторые примеры существующих классов были бы идеальными, к сожалению, большинство ORM, с которыми я сталкивался, используют (только PHP5) PDO учебный класс.
3 ответа
Обязательно выберите вариант 2. Ваш ОО-подход превосходит массивный оператор switch. Ваш базовый класс даст вам больше, чем просто наследование общих методов. Он дает вам непротиворечивый интерфейс, который впоследствии можно будет использовать в качестве адаптера при переходе на другую стратегию сохранения базы данных (PHP5/PDO, когда управление приходит в себя?). Я бы даже тщательно смоделировал ваш интерфейс после PDO до такой степени, что PDO может даже стать заменой вашего собственного уровня персистентности в случае необходимости. Кроме того, кривая обучения для новых разработчиков проекта, изучающих ваш уровень персистентности, будет ниже, если они уже имеют опыт работы с PDO.
Если кто-то ищет что-то похожее (я не надеюсь на это), но если - вы должны взглянуть на xPDO.
Это альтернатива для pdo, работающего над php4. Никогда не пытался его использовать - но я думаю, что это должно работать... http://www.xpdo.org/
Я не могу понять управленческое решение использовать абсолютно неподдерживаемое программное обеспечение в качестве основы для разработки нового программного обеспечения. Для менеджера существуют практически нулевые затраты на установку PHP 5 хотя бы параллельно. Единственным следствием PHP 4 являются более высокие затраты на разработку (имеется больше классов PHP 5, чем для PHP 4, в настоящее время все инструменты в основном зависят от PHP 5, а последние напоминания о PHP 4 исчезают), а производство с PHP 5 обходится дешевле - у вас есть самостоятельно исправлять ошибки во время выполнения PHP, PHP 5.3 использует намного меньше системных ресурсов,....)
Но если вы действительно хотите пойти по этому пути: Pear:: MDB2 должен делать то, что вам нужно, он совместим с PHP 4 и очень стабилен.
Но я бы предпочел сменить работу... такие решения обычно не единственные глупые.