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

[delmot]

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

[AdaStreamer]

Двигаемся в сторону Ruby On Rails. Следующим шагом будет использование haml и scss.

[AdaStreamer]

Ну может кто-нибудь прокомментирует из заминусовавших в чем я не прав? Речь идет об автоматизации работы с субд немного другого уровня. Я не говорю, что это не надо делать. Надо, конечно надо, и огромное спасибо автору за освещение этого вопроса и безусловно ему надо продолжить цикл статей, освещающих тему ar. Просто интересно наблюдать как пхп-шные программисты постепенно начинают использовать то, что уже давно успешно работает на рельсах.

[SowingSadness]

AR на PHP уже 1000 лет. При чём тут RoR?

[AdaStreamer]

при том, что у меня не получилось найти нормальный фреймфорк на пхп, использующий ar. Наверное, уместнее сравнивать не фреймворк и язык, а фреймворк и фреймворк.

[AdaStreamer]

а точнее — сравнивать использование библиотеки по паттерну ar в контексте языка и использованиее библиотеки внутри фреймворка

[SowingSadness]

Надеюсь открою вам глаза: www.yiiframework.com

[VolCh]

PHP уже обогнал Ruby и вовсю юзается DM :)

[hell0w0rd]

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

[hanovruslan]

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, проверка версионности) а в конструкторе базового класса библиотеки оставить только то, что непосредственно к этой сущности относится?

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

[SowingSadness]

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

Orm::getModel

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

Можете расписать почему, я например, не понимаю :(

[hanovruslan]

Все очень просто. Класс Orm — это у вас и ядро, и обработчик конфигураций, и создатель моделей, и автолоад — 4 ответственности. А тот самый принцип («Single responsibility principle») предлагает вам делать это в разных — то есть в 4-х — классах.

и еще про автолоад немного, Если ваши класс именуются по PSR-0, то автолоад обернутый в метод какого-нибудь класса вам в принципе вообще не нужен. можно делать через выделенную функцию.

[SowingSadness]

Автор не я. А про другие ответственности, то что он ещё и Autoload и обработчик конфигурации я грешен, не прочитал в статье :)
Просто удивился из названия, чем это плохо.

[JoomCheese]

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

[arztx]

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

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

[arztx]

Если кому интересно, могу написать подробнее, хотя там все просто.

[not_ice]

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

[JoomCheese]

Конструкция Book::all() не сможет работать по нескольким причинам: в автозагрузчике классов моделей AR необходимо указывать путь к каталогу содежращему эту модель. В примере простейший случай рассматривается — все в одной папке, в реальности у нас модели могут находиться в нескольких папках и автозагрузчик просто не будет знать где их искать, также нужно учитывать пространство имен в которых определены наши модели, AR работает в своем пространстве ActiveRecord, а модели могут быть определены в глобальном, тогда надо будет писать так \Book::all(), предварительно задав необходимый каталог через

$config = Config::instance();
$config->set_model_directory('Путь_к_папке_с_классом_модели');