Прикручиваем ActiveRecord к сайту

Дабы не изобретать ещё больше велосипедов, ActiveRecord следует подключать через composer

Вся статья — один большой антипаттерн

AR как следует из ссылки на packagist — это паттерн и, как в случае того пакета, библиотека. Очевидно, что в первую очередь это паттерн. Если я ничего не путаю первая более или менее путная реализация этого паттерна (как и все остальное путное и полезное) — это PropelOrm, который по дефолту был в симфони с самого начала до версии 1.2 включительно. Потом симфонийцы решили, что DataMapper полезнее будет и перешли к доктрине. когда были первые удачные (в том смысле слова, что они достаточно хорошо работают, чтобы их использовать на конвеере в продакшене) реализации были у RoR — я не знаю. Не писал ничего на нем кроме тьюториала ) Важно другое, Паттерн рабочий, а вот реализация в данном посте, как мне кажется не очень удачная.

1. Взять хотя бы нарушение хорошего (в том же смысле, что и удачного) принципа «delegation instead of inheritance».

От класса Model мы будем наследовать все модели существующих таблиц

2. «new Controller;» в конца файла с исходниками этого класса — тут сишники плачут кровавыми слезами

// ... } new Controller; ?>

3. автолоад «размазанный» по классу Orm. Это минус потому что (опять очевидно) автолоад — не является специфической задачей для любой прикладной библиотеки

4. в том месте, где у уважаемого автора идет

Orm::getModel

это паттерн фабричного метода. нарушение одного из принципов SOLID — конкретно того, что спрятан за буквой S

5. Самый критичный кусок фукционала, ИМХО, define, die и инклюды в конструкторе Orm. Почему бы вам такую тяжелую инициализацию этой библиотеки не вынести в отдельные метода/файлы (автолоад, define, проверка версионности) а в конструкторе базового класса библиотеки оставить только то, что непосредственно к этой сущности относится?

Это не плохо, раз уж работает, но по этим самым причинам разработка как и развитие вашего решения будет медленнее, если бы этих минусов не было

Рад слышать много конструктивных замечаний! Конечной целью сего является создание отдельного модуля(компонента) ORM на базе AR, который можно просто распаковать в папку и буквально за пару строк кода проинициализировать, в итоге получить объект посредством которого используя все методы AR будем управлять всеми нашими данными в БД. Без использования дополнительных тулсов(вроде composer) и не зависимо от наименования классов(PSR-0 к примеру, во фреймворке модели могут располагать и именовать по разному, в моем случае я ввел ограничение на наименование внутри папки моделей — имя файла должно совпадать с именем класса модели внутри). Не зависимо от паттерна проекта, компонент должен максимально просто встраиваться и работать.

У меня тоже была подобная проблема.
После недолгих раздумий решил взять и query builder, и ar от известного framework-а laravel. Главное что все это чудо имеется на packagist.org под именем illuminate/database.
Все что надо это подключить библиотеку через composer и далее по инструкции инициируем: github.com/illuminate/database

Все быстро и красиво.

Вообще не понял, почему используется
$model = Controller::$ORM ->getModel('Book'); $books = $model->all();
когда во всех примерах документации PHPActiveRecord предлагается делать так:
$books = Book::all();