YiiFramework Yii PHP framework 2 public preview

[MiksIr]

Я вот тут посмотрел AR. А можете пояснить на пальцах, в чем плюсы разделения AR на AR+AQuery? Вот минусы с точки зрения использования - вижу, это и проблемы с автокомплитом, и излишняя магичность скоупов. Просто разделили, так как слишком много ответственности? Ну AR вообще весь такой. Тот же Фаулер гвоорит, что не видит причин выносить методы поиска в отдельный файндер из AR.

 

[grigori]

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

 

[MiksIr]

Всем, конечно, очень интересно, почему grigori не будет писать ответ. Ок.

 

[grigori]

если учесть, что ответ знают примерно 5 человек в мире - спрашивай у кого-нибудь, ага,

впрочем, может Саша захочет ответить, хз, но я бы его спрашивал иначе

 

[MiksIr]

MiksIr, совершенно лень как-бы расписывать тут логику

если учесть, что ответ знают примерно 5 человек в мире

Ну как бы очень скромно, да.
Те делать нечего? Не будет ответа, так не будет. Не переживай за меня.

 

[MiksIr]

А вопрос именно тут (на этом форуме), ибо мне кажется, что я помню тему, где обсуждался AR именно в этом ключе, т.е. что файндер в AR - недостаток, и его нужно вынимать. Вот мне и интересно вспомнить, в чем тут дело. Только в том, что класс толстый получился, или еще в чем-то.

 

[fixxxer]

Я могу предположить, что для абстракции от структуры AR-модели, навязываемой SQL, и избыточной для документного стораджа. Хотя я бы обошелся трейтами.

 

[grigori]

fixxxer, трейты были отвергнуты году сначала потому что min 5.4 ставить, как я предлагал, не хотели - типа, мы вот-вот альфу выкатим к зиме, а когда по факту прошло 2 года и этой осенью требования подняли до 5.4 - менять архитектуру уже поздно,
а во-вторых кагбэ потому что их нельзя параметризовать как поведения

 

[fixxxer]

Я делаю псевдопараметризацию трейтов через интерфейсы и объявленные через @method геттеры, которые должен реализовать использующий трейты класс.
Но, конечно, generic-ов не хватает.

 

[Gas]

После того как объявили о 5.4, то зарефакторили AR и вынесли часть логики в трейты

 

[grigori]

понятно, что выкрутиться можно, но классы ядра должны быть быстрыми и понятными, а параметризация через геттеры - это не совсем здравая идея для API популярного фреймворка

Gas, на самом деле причины разделять AR и finder были, и в данном случае трейты были бы таки костылем, а не решением

 

[fixxxer]

Это спорный вопрос, что проще - явно указанные в @method-комментариях и явно вызываемые геттеры, или __call-магия. Оба варианта по сути workaround-ы ввиду отсутствия templates/generics

 

[MiksIr]

После того как объявили о 5.4, то зарефакторили AR и вынесли часть логики в трейты

Из ActiveQuery правда. Может это только этап, и потом эти трейты в AR уедут.

Я могу предположить, что для абстракции от структуры AR-модели, навязываемой SQL, и избыточной для документного стораджа. Хотя я бы обошелся трейтами.

В смысле, что бы этот AR можно было бы под noSQL подпихнуть? Почему бы тогда просто не разделить на два слоя наследованием - базовое, а слоем выше - для реляционных. С чем работаем, от того и наследуем модель.

 

[grigori]

в данном случае не делали ни магию, ни геттеры, а разделили логику на разные независимые сущности

 

[fixxxer]

Делегирование гибче наследования, а так тоже вариант.

 

[MiksIr]

понятно, что выкрутиться можно, но классы ядра должны быть быстрыми и понятными, а параметризация через геттеры - это не совсем здравая идея для API популярного фреймворка

А запихнуть скоупы статикой в модель, а потом вызывать их магией через объект ActiveQuery - это как?

 

[grigori]

это ... холивар на тему, к которой я не имею ни малейшего отношения
любовь к статике и внутренняя связанность через хардкодинг классов - это, считай, такая фича великого кормчего

 

[fixxxer]

Я если честно вообще в код не смотрел, я рассуждаю исходя из имен классов.

В моем понимании здравая архитектура при таком разделении - это когда модель изнутри делает new ActiveQuery, инициализирует своей структурой, получает результат и грузит в себя. Хотя это получается похоже на table gateway, только с иным разделением

 

[grigori]

в том и суть - в yii никакой не AR, и не table gateway, а пришей кобыле хвост,
то есть конструкция с одной стороны удобная, а с другой в рамки паттернов нифига не укладывающаяся

 

[MiksIr]

Я если честно вообще в код не смотрел, я рассуждаю исходя из имен классов.

В моем понимании здравая архитектура при таком разделении - это когда модель изнутри делает new ActiveQuery, инициализирует своей структурой, получает результат и грузит в себя. Хотя это получается похоже на table gateway, только с иным разделением

В Yii модель в статическом методе создает AQ, и отдает ее, и дальше уже мы все методы включая итоговый find вызываем у AQ, а тот уже возвращает модели. Так как AQ создана статикой - у нее нет объекта AR. Благодаря этому и со скоупами фигня - они вроде как должны быть в AR, как часть бизнес-логики, а вызываются у AQ.