Новости Yii 2021, выпуск 1

[D_E_S]

Отличные новости, ждём пакет с адаптацией CycleORM под Yii3! т.к. нам в Yii2 не хватает полноценной ORM, которая реализована по модели DataMapper. Так-же кому интересно про ЭФКО можно подробней ознакомиться на Хабр.Карьера https://career.habr.com/companies/efko

[NikoX]

Есть расширение vjik/yii2-cycle и ещё панель к дебаггеру vjik/yii2-cycle-debug.

В целом рабочее решение, позволяет работать с Cycle ORM в Yii 2.

[SamDark]

https://github.com/yiisoft/yii-cycle, в принципе, рабочий уже. Но пока не тегнут.

[topuserman]

Искренне не понимаю, зачем нужен этот бестолковый фреймворк, напичканный антипаттернами со всех сторон.

[SamDark]

А можно указать на конкретные антипаттерны в коде Yii 3? Сейчас самое время, успеем поправить, если что.

[GoodGod]

Не критика. У нас админка на Yii2. Должен сказать благодаря виджетам Yii2 это самая гибкая админка, которую я когда-либо видел — можно добавить любую кнопку или список куда угодно. Например админка Битрикс кастомизируется не во всех местах. Есть вопросы и к админке Laravel — Nova, т.к. сильно переделать ее (чтобы один список выглядет по одному, а другой список сущностей — совершенно по-другому) довольно напряжно. Но конечно Enterprise'у надо от фреймворка еще дофига всего кроме этого.

[yii2-developer]

Улучшены ошибки DI контейнера

Опечатка .

[SamDark]

Вроде нет.

[viktorprogger]

Речь о том, что текст исключений. выкидываемых контейнером, стал более информативен. Так что да, ошибки улучшены :)

[first-programmer]

Отлично) Ждем полноценного релиза) Есть вопрос про базовый шаблон. Будет ли какой-то шаблон приложения с примером нормальной архитектуры, типа DDD. Я смотрел ваше видео, где вы говорите, что не делаете такой шаблон, так как для новичков сложно. Но мне как программисту со стажем, но при этом еще только въезжающему в нормальную архитектуру наоборот кажется, что будет полезно посмотреть на нормальную арзитектуру и на ее основе начать учиться это все дело использовать. Сейчас в yii2 (а я сам с него начинал изучение фреймворков в php) большинство разработчиков берут шаблон, который там по умолчанию идет (базовый или продвинутый) и идут по накатанной, делая проекты, которые разрастаясь превращаются в треш-код. Например часть логики пихают в контроллеры, часть в модели AR. При этом мало кто знает, что есть сервисы. А те, кто как я знают, не еще не умеют использовать на практике сталкиваются с проблемой, что посмотреть-то негде. Например, я вообще пока не понимаю, что тут должно быть сервисом, что entity и зачем вообще тогда AR. Вроде entity, если я правильно понимаю концепцию DDD, должны хранить параметры модели, то есть ее свойства и методы. То есть по факту это и есть AR? И вот таких вопросов куча, а хочется какой-то шаблон, который бы помог посмотреть, как это все лучше делать. То есть инструмент вы даете отличный, но чаще всего это как граната в руках обезьяны) Я стараюсь на сколько хватает архитектурных знаний держать код в хорошем виде, но по факту, раз есть такие крутые разработчики, которые могут показать как правильно, то почему бы и не сделать некий шаблон с описанием. Пусть те, кому не нужно качают старый привычный модульный шаблон, пишут в виде transaction script.

[SamDark]

Просто из шаблона DDD не понять. Толку не будет. В документации опишем как надо, дадим ссылок.

[first-programmer]

Понял) Спасибо за труд) Читаю уже сегодня примерно пятую статью на тему DDD, вроде что-то и вырисовывается, но только в рамках концепции, а не реального применения. Буду надеяться, что в документации у вас действительно появится пример того как работать с DDD в рамках Yii3 или Yii2, чтобы можно было на примере посмотреть, что и где использовать)

[first-programmer]

Пока надеюсь, что найду какой-то полезный материл, например у Дмитрия Елисеева)

[OKyJIucT]

Видел видео от Дмитрия Науменко про DDD. Он по моему тоже участвовал в разработке Yii.

[SamDark]

Да, Дмитрий — часть команды основной. Активно участвовал в поддержке и развитии Yii 2.

[michael_v89]

Будет ли какой-то шаблон приложения с примером нормальной архитектуры

В Yii самая подходящая архитектура такая. Есть контроллеры, в них через DI передаются сервисы, в методах контроллера вызываются методы сервиса, в методы сервиса передается валидированная форма, соответствующая действию которое вы хотите совершить. Для списка например там будет форма с фильтром, для создания/редактирования форма с полями сущности, которые пользователь может ввести в интерфейсе. Сервис это просто ваш класс с логикой обработки, который вы сами написали. Бизнес-логику в сущностях AR не стоит писать, они плохо для этого подходят. Названия полей с переводом тоже, их надо писать в классах форм, а не в классах ActiveRecord, которые в базу сохраняются. Логика в сервисах, валидация в формах. Это удобное правило, которое будет работать в любом фреймворке.

[first-programmer]

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

[michael_v89]

Ну я могу сказать только, что "логика в сервисах" это работает. Со временем я пришел к выводу, что так удобнее. Это не только логика, которая затрагивает несколько сущностей, это еще и создание/удаление. Сущность не может сама себя создавать и удалять, значит этот код должен быть где-то еще, а редактирование удобнее делать там же, где и создание. И зависимости в сервисы пробрасывать проще, чем в сущности.

[michael_v89]

Yii 3
Прежде всего, релизы:
В каждом пакете есть документация, отличное покрытие тестами, код вычищен и, конечно же, публичный API достаточно стабилен.

Блин, ребята, пока вы Yii 3 делали, я уже 2 работы сменил. На первой из них мы всерьез рассматривали Yii как фреймворк для нового проекта, но решили делать на Laravel, потому что у вас были непонятные перспективы когда вы это всё закончите.

Мне кажется, вам надо было бы сделать только ORM и GridView с новой архитектурой, и сразу выпустить первую версию, остальное бы вам сообщество сделало кому что надо. Но вы решили всё делать сами, и это проблема, это непонятные сроки разработки и непонятные перспективы развития.

[Lisio]

Александр, какие у вас планы по yii-mongodb? Есть надежда на релиз этого пакета и насколько жестоко он будет связан с основным пакетом ActiveRecord для реляционных бд? По личным впечатлениям yii2-mongodb до сих пор единственная адекватная ORM для работы с монго без существенных костылей.

[SamDark]

М… А как же официальный SDK? Костыли?

[Lisio]

Если вы про MongoDB PHP Library, то я не могу отнести ее к разряду ORM.

[SamDark]

Ясно. Если релиз будет, то будет связан с основным AR. Именно так было в Yii 2.

[kirik]

Нельзя NoSQL засунуть в парадигму ORM, ибо вторая буква тут никак не применима. Посмотрите в сторону доктриновского ODM. Но и то всё это выглядит крайне костыльно, увы.

[SamDark]

У нас выглядит не крайне костыльно. Но да, большая часть фич специфичных просто теряется.

[krch_Vova]

github.com/yiisoft/cache-apcu/blob/4c9c7e396f5ef830a75f9d8f6558835942e2ee66/src/ApcuCache.php#L200 В прошлых релизах метод что-то делал или какой-то странный кейс?)

[SamDark]

Действительно странно. Проверим. Спасибо.

[SamDark]

Так и надо:

Normalizes keys returned from apcu_fetch() in multiple mode. If one of the keys is an integer (123) or a string representation of an integer ('123') the returned key from the cache doesn't equal neither to an integer nor a string ($key !== 123 and $key !== '123'). Coping element from the returned array one by one to the new array fixes this issue.

https://github.com/yiisoft/cache-apcu/pull/20

[wildan]

Спасибо Вам огромное и Картику. Вы с ним не сотрудничаете?

[SamDark]

Нет, не сотрудничаем.