Идея: лёгкий ActiveRecord

[samdark]

т.к. AR кушает память и процессор, но всё-таки в выборках и построении запроса очень удобен, возникла идея сделать поведение, перекрывающее populateRecord и отдающее либо простейшие голые объекты или же вообще массивы вместо полноценных объектов AR.

Поведение можно будет подключать когда необходимо только вывести данные, не производя с ними каких-либо действий:

Код: Выделить всё

$post = Post::model();
$post->attachBehavior("lightAR", new LightAR());
$posts = $post->with('Comment')->findAll();
// далее только отрисовываем записи
 

[Ekstazi]

Вариант, но, не уверен что behavior здесь подходит, и, судя по тому что я видел по коду, метод populateRecord(-s) здесь не подходит(так как behavior его не перекроет). Нужно писать свой компонент, унаследованый от CModel. Причем с операциями поиска и обновления(вставки) там все очень просто, сложнее с отношениями и связями.

[samdark]

Почему не отнаследованный от CActiveRecord?

[Ekstazi]

Стоит наследовать от CModel, так как CActiveRecord тянет метаданые и прочие излишества при излишиства(это можно исправить), да и компонент я так понимаю лучше сделать независимым от cActiveRecord(в дальнейшем это позволит его легко портировать под любой фрэймвок).

[samdark]

Так он же тянет их во время и после запроса. Если всё оставить, а вот это подтягивание перекрыть — будет немного обрезанный AR, но работающий быстрее. Смысла портировать на другие фреймворки я не вижу, в других фрейморках есть свои решения.

[Ekstazi]

По-моему с нуля все же интересней, тем более взять наработки pirat а и доработать их и можно получить сильную альтернативу CActiveRecord.

[samdark]

Альтернативу-то мы получим, но под неё неподготовленному программисту придётся переучиваться. А тут тот же AR, только возвращающий немного не такие объекты или вообще массивы.

Кстати, в виде поведения очень даже хорошо получится. Особенно если методы назвать по-другому, например: Post::model()->getAll()->with(X);

[Ekstazi]

Только если названия другие, тогда да

[Papa Stifflera]

Не нужно городить огород. Для начала, почитайте что нибудь об объектно-ориентированном проектировании.

ActiveRecord - это шаблон проектирования (design pattern) со всеми вытекающими последствиями. Есть и другие реализации этого шаблона. Например, классическая реализация. Так что не стОит городить огород. Вам дали в руки замечательный инструмент. И даже два (это я про DAO). Если вы пишете очередную поделку, которая будет хоститься на shared-хостинге - используйте DAO. Если работаете над серьезным проектом с нормальным бюджетом, который в последствии будет/должен масштабироваться и сопровождаться командой программистов - ActiveRecord самое оно.

Друзья! Я понимаю, что немного оскорбил некоторых своим категоричным тоном. По этому прошу за это прощения. Помните, что хорошими программистами не рождаются - ими становятся. Лично у меня 15 за спиной 15 лет коммерческой разработки, в том числе 4 года на PHP и 2 года на Ruby. Не поленитесь, прочтите что нибудь про шаблоны проектирования. Например, есть замечательная книга "PHP, объекты, шаблоны и методики программирования", автор Метт Зандстра. Очень познавательное и полезное чтиво. Ну и классика, под авторством "банды четырех" "Design Patterns: Elements of Reusable Object-Oriented Software". Я думаю что те, кто найдет в себе силы/желание осилить хотя бы один из этих трудов, на программирование будет смотреть в совершенно в ином свете.

Спасибо за внимание!

[Ekstazi]

Наверное вы не поняли суть топика. Если вы такой успешный программист, то покажите хотя бы один из ваших проектов в ООП стиле. Sam предложил реализовать более легкий класс на основе ActiveRecord патерна. Да и лучше всего про шаблоны проективание пишет Мартин Фаулер. Его и надо было советовать. Поэтому у меня возникли большие сомнения на счет вашего професионализма. Ну да не будем ругаться. Как профессионал лучше вылоэжите свои идеи по упрощению функционала класса CActiveRecord в yii или любой другой способ работы с БД.

[Papa Stifflera]

Наверное вы не поняли суть топика. Если вы такой успешный программист, то покажите хотя бы один из ваших проектов в ООП стиле. Sam предложил реализовать более легкий класс на основе ActiveRecord патерна. Да и лучше всего про шаблоны проективание пишет Мартин Фаулер. Его и надо было советовать. Поэтому у меня возникли большие сомнения на счет вашего професионализма. Ну да не будем ругаться. Как профессионал лучше вылоэжите свои идеи по упрощению функционала класса CActiveRecord в yii или любой другой способ работы с БД.

Гыг. В следующий раз я непременно учту Ваши замечания, уважаемый, по поводу списка литературы. И непременно опубликую названия и авторов ВСЕХ книг (известных мне), касающихся темы обсуждения.
Показать проекты===показать исходный код. Увы, у меня пока нет проектов Open Source. Есть задумки, но до реализации не доходят руки. Как только сподоблюсь - обещаю, Вы первый получите уведомление. А от Ваших сомнений в моем опыте/профессионализме мне ни холодно, ни жарко.

А теперь по теме...

На вскидку... Основное время/ресурсы системы тратятся на создание массива объектов (которые и нужны-то не всегда) модели (методы PopulateRecord()/PopulateRecords(), если не ошибаюсь) на основе результатов выборки из БД. Создайте класс-контейнер, который:
1) будет содержать результаты запроса к БД "как есть", т.е. в виде массива;
2) должен знать тип класса AR, который хранит;
2.1) должен уметь создавать экземпляры объектов нужных классов "на лету" по требованию (класс нам известен);
3) может отдавать массив результатов (выбранных из БД) в виде массива в режиме read-only;

При таком подходе не теряется вся мощь AR (элементы массива преобразуются в экземпляры классов AR при желании и прозрачно) и не кушается много памяти/ресурсов, если нужно, например, отобразить список пользователей (просто пробегаемся по массиву без создания объектов AR). Можно спокойно отнаследоваться от CActiveRecord и перекрыть несколько методов особо не опасаясь изменений в коде CActiveRecord.

Такой подход я использую в своей библиотеке для MongoDb. Но, поскольку, MongoDb не реляционная БД, то там немного другая песня и свои заморочки.

[samdark]

Идея с созданием «честных» объектов по требованию занятна. Остальное вроде уже было озвучено. Если есть готовый код — делитесь. Оттестируем, допилим, напишем модульных тестов.

Кстати, в данный момент пишу аналог AR для MongoDb. Может стоит скооперироваться?