Статья — это прочтение графиков и выводы. Графики удобнее смотреть в полуинтерактивном режиме по ссылке, которого, естественно, не будет, если просто вставить сюда скриншоты. Ну и я постоянно обновляю эти тесты, так что устарело бы очень быстро.
Раннер грузит кофиги, создаёт контейнер, наполняя его конфигурацией и вот это всё. Можно свой сделать или вообще в своём index.php без всякого раннера работать. Параметры конструктора runner-а — это как раз конфиг начального запуска. Дальше как раз всё разруливается контейнером.
Чтобы что-то заменить, нужно раннер сделать свой. В Yii3 два типа пакетов: те, что чисто под Yii, они префиксируются как yii- и независимые пакеты, которые без префикса. Те, что префиксированы — там мы не смотрим на расширяемость и заменямость и просто подразумеваем что работать будем с плюс-минус умолчаниями. В не Yii-специфиычных всё наоборот.
По поводу .env у нас было мнение что его 1) не будут юзать в проде 2) загрузки через docker compose достаточно. Это мнение не оправдало себя, переделаем затащим на борт тот же vlucas.
Сам эксперимент интересный, но проведён предельно грубо. Думаю, в вашем случае это можно и компанию похоронить... Можно было объяснить что это и зачем, какие гипотезы он хочет проверить, мотивировать остальных действительно влиться в эту штуку, а не саботировать её. Глядишь, что-то и вышло бы. К осознанному коду вернулись бы обязательно, но с пониманием и новыми инструментами.
Интерфейсы не завсят от PDO (но сам пакет да, там часть реализации именно под PDO). По идее, можно реализовать и сейчас. В идеале, вынуть оттуда PDO-часть в отдельный пакет. Не уверен только на тему промисов и обработки результатов.
Это частично расписано в статье. Личная цель была в том, что я сделал несколько больших коммерческих проектов и на Laravel и на Symfony и на Yii2 и не был до конца доволен ни одним из них.
Для меня лично:
быстрый DI-контейнер, который при этом не компилится. В Symfony компилится, в Laravel не быстрый, в Yii2 уже норм, но мало используется по назначению.
форсирование нормального depdendecy inversion, отсутствие service locator. В Laravel сервис локатор и "фасады" несколько всё портят. В Symfony в меньшей степени.
PSR. В Yii3 нативный, в Symfony через адаптеры и не всё. У Laravel как у Symfony потому что юзает компоненты Symfony.
Качество. Такого покрытия тестами, пожалуй, ни у кого больше нет.
Открытость к PHP. Остальные фреймворки довольно закрыты к остальной экосистеме.
DBAL. yiisoft/db прекрасен.
Можно как угодно делать себе архитектуру и фреймворк не будет мешать. Я люблю вертикальные слайсы.
Много классных пакетов и возможность использовать любые PHP-пакеты. От того же Symfony, например, или PSR-совместимые. Контейнер отлично справляется с их конфигурацией.
Когда SOLID и архитектурные паттерны используются чтобы были без понимания зачем, проекту становится очень плохо очень быстро. Когда не используются... получается даже немного лучше на короткой дистанции. На средней-длинной начинается лавина техдолга.
Статья — это прочтение графиков и выводы. Графики удобнее смотреть в полуинтерактивном режиме по ссылке, которого, естественно, не будет, если просто вставить сюда скриншоты. Ну и я постоянно обновляю эти тесты, так что устарело бы очень быстро.
Так откройте ссылку.
Добавил.
О, и правда workerman хорош!
О, добавлю тоже.
Да, надо добавить тоже…
Тогда смотрите на то, что помечено как classic.
Занятно. А чего не взять наследника двух предыдущих поколений из пакетов Yii3?
http://github.com/yiisoft/db
https://github.com/yiisoft/active-record
Шаблоны и плагины можно на PHP писать.
https://yiipress.yiiframework.com/ будет покруче по способности нагрузку держать :)
Мне нравится. Вероятно, испробую в одном из OpenSource проектов.
Раннер грузит кофиги, создаёт контейнер, наполняя его конфигурацией и вот это всё. Можно свой сделать или вообще в своём
index.phpбез всякого раннера работать. Параметры конструктора runner-а — это как раз конфиг начального запуска. Дальше как раз всё разруливается контейнером.Чтобы что-то заменить, нужно раннер сделать свой. В Yii3 два типа пакетов: те, что чисто под Yii, они префиксируются как
yii-и независимые пакеты, которые без префикса. Те, что префиксированы — там мы не смотрим на расширяемость и заменямость и просто подразумеваем что работать будем с плюс-минус умолчаниями. В не Yii-специфиычных всё наоборот.По поводу
.envу нас было мнение что его 1) не будут юзать в проде 2) загрузки черезdocker composeдостаточно. Это мнение не оправдало себя, переделаем затащим на борт тот же vlucas.Сам эксперимент интересный, но проведён предельно грубо. Думаю, в вашем случае это можно и компанию похоронить... Можно было объяснить что это и зачем, какие гипотезы он хочет проверить, мотивировать остальных действительно влиться в эту штуку, а не саботировать её. Глядишь, что-то и вышло бы. К осознанному коду вернулись бы обязательно, но с пониманием и новыми инструментами.
https://github.com/yiisoft/db/issues/1149
Интерфейсы не завсят от PDO (но сам пакет да, там часть реализации именно под PDO). По идее, можно реализовать и сейчас. В идеале, вынуть оттуда PDO-часть в отдельный пакет. Не уверен только на тему промисов и обработки результатов.
Синтаксис более явный, чем у вас. Но ваш тоже норм.
Это частично расписано в статье. Личная цель была в том, что я сделал несколько больших коммерческих проектов и на Laravel и на Symfony и на Yii2 и не был до конца доволен ни одним из них.
Для меня лично:
быстрый DI-контейнер, который при этом не компилится. В Symfony компилится, в Laravel не быстрый, в Yii2 уже норм, но мало используется по назначению.
форсирование нормального depdendecy inversion, отсутствие service locator. В Laravel сервис локатор и "фасады" несколько всё портят. В Symfony в меньшей степени.
PSR. В Yii3 нативный, в Symfony через адаптеры и не всё. У Laravel как у Symfony потому что юзает компоненты Symfony.
Качество. Такого покрытия тестами, пожалуй, ни у кого больше нет.
Открытость к PHP. Остальные фреймворки довольно закрыты к остальной экосистеме.
DBAL. yiisoft/db прекрасен.
Можно как угодно делать себе архитектуру и фреймворк не будет мешать. Я люблю вертикальные слайсы.
Много классных пакетов и возможность использовать любые PHP-пакеты. От того же Symfony, например, или PSR-совместимые. Контейнер отлично справляется с их конфигурацией.
Понял. Чуть подробнее распишу тогда про это в кукбуке.
Когда SOLID и архитектурные паттерны используются чтобы были без понимания зачем, проекту становится очень плохо очень быстро. Когда не используются... получается даже немного лучше на короткой дистанции. На средней-длинной начинается лавина техдолга.
Переменные устанавливает не XDebug, а вы сами. Судя по всему, нужно собрать рецепт по XDebug.
Да вроде запускаются через
make up. Что-то не работает?