Как назвать метод?

[Vano]

Как назвать метод в Yii2 который возвращает ActiveQuery со всем нужными реляциями.

public static function ...()
{
    return self::find()->joinWith(['profile', ...])->with('city');
}

 

[fixxxer]

IShouldHavePutThisCodeInASeparateClassButIAmTooLazy

 

[whirlwind]

Все резко меняется, когда пытаешься смотреть с точки зрения TDD. Если от сложного диалекта не избавиться, то такое г нужно завернуть во что нибудь мокируемое. Если можно не использовать сложный диалект который поверх другого сложного диалекта, его нужно не использовать. Строки никогда не решали задач контрактов. Так что эти все ваши factory/builder идентификаторы (в том числе в IoC) это все вилами.

 

[Vano]

Тааак... не уверен. Хоть я и согласен с

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

но кажется, что куда уж дальше уж.
Есть экшн контроллера, который показивает список юзеров (с аватарками из профиля, и именем города, в котором они живут), к find() я добавляю некоторые join'ы. Был бы это один join, я бы сделал это в контроллере, но так как, я использую часто такой join, хочу вынести его в отдельный метод. А название этого метода должно зависить от слов: find, "набор джойнов", предпросмотр. Вот смысл моего вопроса.
Тогда если, нужно завернуть во что нибудь мокируемое, то во что? У меня есть идея, что из этих всех моделей (которые по сути тупо АктивРекорды), нужно слепить одну модель, которая и будет представлять пользователя всего. Но как? подскажите.

 

[fixxxer]

join

в контроллере

Писать в контроллере SQL - уже все понимают, что неуместно. Но почему-то тот же SQL, выраженный промежуточным языком, многие считают приемлемым.

 

[Вурдалак]

Yii и качественный код — взаимоисключающие параграфы. Yii хорошо подходит тем, что хочет максимально быстро получить продукт, который будет обречен на постоянные баги до конца дней своих.

 

[Redjik]

ну уж не баги...
а на провалы в архитектуре и костыли
каждому инструменту свое применение

 

[Вурдалак]

За костылями и «провалами» в архитектуре всегда следуют баги. Рано или поздно это превращается в игру «тут приклею, там подопру». Разобраться в бизнес-логике будет становится все труднее, местами она будет неконсистента. Проект превратится в обузу в том смысле, что уже удовольствие от программирования будет все меньше и меньше. «Ну... Это legacy». А кто это legacy создал? Такие же программисты, как и вы, которые хотят запилить что-то побыстрее и пойти пить пива после работы.

 

[MiksIr]

И виноват в этом Yii. Зато симфони делает конфетку из любого говна Само. Автоматически.

 

[Вурдалак]

Ожидал такого коммента. Нет, нет. В этом виноваты программисты, которые считают, что Yii — это хороший выбор. Значит для них такого уровня код — это норма. Значит у них и в проекте будет такое же дерьмо.

Я вообще сторонник кода, который был бы максимально framework agnostic. С Symfony это достаточно легко. С Yii — формально тоже можно, но нафиг тогда Yii? Большая часть фреймворка будет не нужна.

 

[MiksIr]

Ответ то в общем опять тот же. Типа, раз выбрали Yii - он вас, сука, заставит писать плохо. А как же, там страшные AR и SL И пофиг какой-проект, вернетесь через пару месяцев к нему - а там уже весь ваш код в говнокод превратился.

А в чем смысл framework agnostic? Без сферических коней сами знаете где если.

Вроде как "запросы на ANSI SQL 92" ибо SQL должен быть database agnostinc? Вдруг поменять захотим?

 

[Вурдалак]

И виноват в этом Yii. Зато симфони делает конфетку из любого говна Само. Автоматически.

И виноват в этом McDonalds. Зато в хорошей столовой меню подстроится под любого человека. Само. Автоматически.

Заставляет ли нас McDonalds покупать Биг Мак с колой? Нет. Там ведь есть продаются яблочные дольки, например, и минеральная вода в бутылках, даже сок есть. Ходят ли туда люди, чтобы купить бутылку минеральной воды? Как правило, нет. Туда ходят пожрать, быстро и дешево. А последствия регулярного питания в McDonalds будут печальны. Можно и в хорошей столовой питаться нездоровой пищей, но отрицать разницу по меньшей мере глупо.

А в чем смысл framework agnostic? Без сферических коней сами знаете где если.

Это частный случай implementation agnosticism. Нарушение этого принципа ведёт к загрязнению бизнес-логики, смешению различных слоёв приложения. Чем больше деталей реализации, тем меньше сути. Чем больше бизнес-логика размазана среди деталей реализации, тем труднее соблюдать её согласованность. Чем больше размыты границы у слоёв приложения, тем больше хаоса: какой слой за что отвечает, валидные ли нам пришли данные и т.д. Я сейчас говорю не про радикальный случай, когда пишут вот так, а как про меру сравнения: приложение может чуть больше FA, чуть меньше FA. И чем больше приложение framework specific, тем хуже. Дьявол в деталях (во всех смыслах). Я не хочу приводить конкретные примеры, в отдельном рассмотрении они тебе покажутся не такими убедительными, тут нужен большой ком таких мелочей, чтобы понять, что код является большой навозной кучей.

Короче, я к чему: существует очевидная корреляция между архитектурными навыками и выбором инструмента, такого как Yii vs Symfony. Да, это не означает, что из фреймворка следует такая-то архитектура и наоборот, но статистически такая связь существует. Например, я ни за что не стал бы рассматривать вакансию, где требуется Yii-разработчик, потому что вероятность встретить там коллектив, разделяющий мои взгляды, будет статистически ничтожно мала. Я скорее всего потеряю время, как своё, так и чужое.

 

[stalxed]

MiksIr, я после прошлого разговора с Вурдалак, читаю книгу DDD Эванса.
Там даётся определение анти паттерна Smart UI.
В его минусах:

• Сложно осуществить интеграцию приложений - разве что через базу данных.
• Отсутствует переносимость функциональных модулей и абстракция прикладных моделей. Правила прикладной модели (Ьиsinеss rules) приходится дублировать в каждой операции, связанной с ними.
• Быстрое создание опытных образцов (прототипов) с последующим итерированием затруднено, поскольку недостаток абстрагирования ограничивает возможность рефакторинга.
• Сложность такой системы быстро похоронит все надежды, так что развитие возможно только в сторону дополнительных простых приложений. Невозможно "изящно" реализовать сложные функции и сложное поведение системы.

Плюс по сути один обучаем для обезьян"менее квалифицированных разработчиков", и быстро пишется код, т.е. если напортачили - можно быстро всё переписать.
Имхо Yii кандидат на Smart UI, там удобный CRUD генератор, в Yii2 в комплекте хорошая интеграция с Twitter Bootstrap: нагенерил код, немного подправил за генератором, "закинул" простые бизнес правила - проект готов.
Я на Yii сам писал несколько небольших проектов, обожаю symfony, но для небольших проектов хороший CRUD и интеграция с boostrap в Yii2 - бомба.
Но далеко не уедешь на Yii, ну я бы лучше застрелился...

 

[Redjik]

MiksIr, я после прошлого разговора с Вурдалак, читаю книгу DDD Эванса.

вот тебе чит код тогда
http://www.infoq.com/minibooks/domain-driven-design-quickly

 

[Sufir]

вот тебе чит код тогда
http://www.infoq.com/minibooks/domain-driven-design-quickly

Опаньки, а вот это шик. Перевода не существует?

 

[AmdY]

За костылями и «провалами» в архитектуре всегда следуют баги.

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

Уже пару лет пишу на laravel и форки завёл только для парочки кривых сторонних пакетов, сам фреймворк ни разу не патчил. Был один небольшой проект на yii, тоже ни одного патча фреймворка не делал. Пуска у них не лучшая архитектура, но вот как раз бороться с багами фреймворков не приходится.

 

[Вурдалак]

Слоёная архитектура это ад

Нормальная слоёная архитектура — это просто. Слои — это результат декомпозиции. Если у тебя ад, значит ты не умеешь её готовить.

Угу, тот кто пользуется Doctrine

Doctrine не имеет ничего общего с тем, о чём я говорю. Используй Eloquent, если хочешь, в нормальной слоёной архитектуре это не будет заметно. Правда придётся маппить persistence model (AR) на domain model (plain old PHP object) и обратно на уровне инфраструктуры.

 

[Redjik]

Doctrine не имеет ничего общего с тем, о чём я говорю. Используй Eloquent, если хочешь, в нормальной слоёной архитектуре это не будет заметно. Правда придётся маппить persistence model на domain model и обратно на уровне инфраструктуры.

а кстати как? свой костыль с рефлексией делать, чтобы entity заполнить данными?

 

[Redjik]

Не вот реально взвешиваю за и против, на AR это жесть будет делать.

В случае с доктриной.
За меня уже продуман маппер таблиц на Entity... в инфраструктуре будут только yml файлы, все кешируется, все работает шустро, по памяти не будет проседаний в теории... ибо доктрина массив данных из базы мапит на Entity по конфигу.

В случае с AR.
Сначала вытащаться все данные, потом намапятся на AR модельки, которые сами по себе прожорливые... И да, предположим, создатели фв уже соптимизировали все что можно и этот этап проходит более менее безболезненно.
А дальше?
Пилим свой маппер на entity и с entity на моедльки, пытаемся все оптимизировать и сделать удобно через конфиги... в итоге переписываем половину доктрины.
А профит в чем?

ЗЫ. я просто хотел бы попробовать именно с AR сплясать, но как представлю, сколько там пилить... Может есть другой способ? Но я пока его не вижу.
ЗЫЫ. и эта ... Вурдалак, открой личку уже... как допишу статью/если допишу, захочется твое мнение.

 

[fixxxer]

Redjik, вот такая попытка нагуглилась. extends Entity, это, конечно, не очень ок, но с промежуточным классом типа Acme\Entity extends ORM\Entity, Acme\User extends Acme\Entity - в принципе терпимо.

UPD: внимательнее посмотрел, Query builder-ом наружу, это, конечно, "и вышел-таки снова на Дерибасовскую" Хотя никто не заставляет, да.