Поговорим о Yii 2

    Yii, вероятно, самый популярный PHP фреймворк на просторах СНГ.
    Многие годы он был замечательным инструментом и помогал нам зарабатывать на хлеб с маслом.
    Но стоит ли начинать на нем новые проекты в 2017-м? Я задумался.


    Архитектура фреймворка


    Мысленно вернемся в 2014-й.
    Ожидание второй версии Yii кажется бесконечно долгим, core-разработчики не называют никаких сроков.
    Разработка ведется в закрытом от публики репозитории.


    И вот SamDark презентует Yii 2.0:


    После трёх лет интенсивной разработки...
    Как вы, возможно, уже знаете, Yii 2.0 был переписан с нуля.

    Выходит, архитектура закладывалась в 2014 — 3 = 2011-м году. Или раньше?


    Взгляните на Component.php из Yii 2
    А теперь на CComponent.php из Yii 1
    А теперь на TComponent.php из PRADO Framework — дедушки нынешнего Yii. Выглядит знакомо.


    Истоки самого же PRADO уходят куда-то во времена расцвета Delphi:


    The very original inspiration of PRADO came from Apache Tapestry.
    During the design and implementation, Qiang Xue borrowed many ideas from Borland Delphi and Microsoft ASP.NET.
    The first version of PRADO came out in June 2004 and was written in PHP 4.

    С первой версии нам достались глобальные константы в коде, свой autoloader, своя хитрая система алиасов для файлов и папок.


    Ооооок. Просто напоминаю, что сейчас идет вторая половина 2017-го.


    Приходя к Yii с других инструментов, вы должны понимать, что здесь весь ваш предыдущий опыт становится нерелевантным.
    Yii — это не просто фреймворк, это попытка сделать свою надстройку над языком.
    Все, абсолютно все компоненты Yii наследуются от класса Object, в котором переопределяются __get, __set, __isset и так далее.


    Многие классы наследуются от Component, который наследуется от Object, и в котором еще раз переопределяются все магические методы.


    Благодаря этому все классы фреймворка из коробки умеют бросать события, подписываться на них, могут содержать т. н. behaviors.
    Каждая модель ActiveRecord в вашем приложении неявно наследует 5 классов и реализует 5 интерфесов.
    У всех ваших моделей, так называемых "компонентов", "виджетов", контроллеров, логгеров, хелперов, валидаторов — одни и те же предки.
    image


    Компоненты, их события, поведения… возможно, они имели смысл в PRADO Framework, где "компонентами" были TButton, TAccordion и все вот это.


    Среди достоинств Yii часто озвучивают простоту фреймворка. Но это правда только отчасти.
    Знаете, что происходит, когда вы делаете что-то безобидное вроде $post->title = 'Hello'?
    Вы можете побывать здесь, здесь, здесь, здесь, а также в любом прикрепленном к $post event-у или behavior-у.


    Это может свести с ума во время отладки.


    Не добавляет радости и тот факт, что любой компонент приложения из любого места можно достать через Yii::$app. Эдакий экземпляр приложения и сервис-локатор в одном лице.


    DI-контейнер


    В Yii 2 он есть.
    В нем нет ни compile-time проверок, ни защиты от circular references, ни тегов (как в Symfony и Laravel), ни Contextual Binding (как в Laravel).
    Доступен из любой точки приложения как Yii::$container. Снова.
    Внутри Yii 2 собственный контейнер не используется, а все компоненты лежат в Yii::$app, прямо как в первой версии.


    Интересный факт: Qiang начал писать Yii 2 в 2011 году, а контейнер был добавлен только три года спустя, между 2.0.0-alpha и 2.0.0-beta.


    Active Record


    Если оставить в стороне споры Active Record vs Data Mapper, то реализация AR в Yii очень даже ничего.
    Удобное и лаконичное API, поддерживаются все популярные СУБД. Есть нормальные миграции из коробки.


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


    Фронтенд


    Тут все плохо.
    В Laravel есть Elixir, в Symfony с недавних пор — Webpack encore.
    Yii же не просто не помогает с фронтендом, а еще и добавляет головной боли.


    Для установки Yii 2 вам нужно в принудительном порядке поставить глобально fxp/composer-asset-plugin, для того, чтобы поставить jQuery c помощью composer-а, для того, чтобы установился Yii.


    jQuery входит в обязательные зависимости Yii 2.


    Не припоминаю ни одного другого composer-пакета, для установки которого нужно было танцевать с бубном.
    В проектах с Yii каждый запуск composer install/update происходит утомительно долго,
    т.к. composer каждый раз идет гулять куда-то в глубины репозитория Bower-пакетов.
    Еще мне когда-то пришлось откатывать версию composer-а на более старую, из-за несовмесимости с текущей версией fxp/composer-asset-plugin.


    В качестве альтернативы предлагается использовать дополнительный composer-репозиторий, который кеширует npm и bower пакеты. Что тоже выглядит немного костыльно.


    Если знаете, как поставить Yii без возни с ненужными фронтенд-пакетами — пишите в комментариях.


    Все остальные компоненты


    Абстракция над HTTP, кеширование, логирование… они есть, и они без проблем выполняют свои задачи.
    Конечно же они самобытные, гвоздями прибитые к Yii, и не имплементируют соответствующие им PSR-ы.


    Будущее Yii


    Скорость развития оставляет желать лучшего


    Помните, как долго мы ждали версию 2.0?
    А вы знаете, когда выйдет 2.1? Никто не знает.


    2.0.x: 222 открытых тикета — No due date.
    2.1.0: 58 тикетов — No due date.
    2.2.x: 1 тикет — No due date.


    Т.е. для 2.1 еще не определена дата релиза, а для 2.2 даже примерный скоуп задач. До третьей версии, о которой еще рано даже начинать говорить, мы вряд ли увидим кардинальные изменения в архитектуре.


    Следует признать, что ближайшие конкуренты — Laravel и Symfony — внедряют новые фишки и выпускают версии гораздо резвее. У обоих конкурентов уже есть LTS-версии. Yii 2.1 вроде бы тоже должна иметь long-term support.


    Компонентные фреймворки победили


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


    Код, написанный на PHP, работает везде, а код, написанный на Yii — только на Yii.
    Вы либо ставите на Yii всё, либо ничего. Это риск для долгосрочного проекта.


    Конечно, приложив усилия, можно писать framework-agnostic код и разруливать все через DI-контейнер, но это не поощряется.
    Если вы все-таки решитесь на это, вам прийдется забыть про Yii-вский ActiveRecord
    или начать писать неприлично толстые прослойки между фреймворком и вашей бизнес-логикой.
    Но это, мягко говоря, неоправданно.


    Если вы наследуете какой-либо класс своего приложения от любого другого класса Yii, без Yii вы его работать не заставите, ведь он обязательно наследует Object или Component. Вот.
    Даже если вы вытащите вместе с ним весь ворох родительских классов и реализуемых интерфейсов, это вам не поможет.
    С модными нынче DDD и CQRS/Event Sourcing Yii также вам не помощник. Скорее, даже будет вставлять палки в колеса.


    Команда фреймворка всё пишет сама. Даже VarDumper они написали свой, а не взяли из компонентов Symfony.
    Регулярно поддерживать и улучшать столько компонентов — очень непростая задача для небольшой команды. И у этой команды есть два пути.


    Во первых, можно оставить все как сейчас.
    Все компоненты пишем сами. Сильная связанность. Полностью изолированная экосистема фреймворка. Небольшое уютное комьюнити. Медленная деградация.


    Во-вторых, можно все-таки разбить монолитный Yii на независимые от фреймворка компоненты.
    Но тогда это будет уже не Yii с простым и удобным API, а просто еще один набор компонентов, не востребованный вне экосистемы Yii.


    Оба пути ведут в никуда.


    PHP 7


    Yii 2 без проблем работает под PHP 7+.
    Однако чтобы использовать все возможности type-hinting-а, core-разработчикам придется переписать его до неузнаваемости.
    Дело в том, что сейчас много методов принимают аргументы нескольких типов:


    // Поиск записи по первичному ключу со значением "42"
    SomeModel::findOne(42);
    
    // так тоже работает
    SomeModel::findOne(['id' => 42]);
    
    // Вернет первую найденную запись, у которой PK - одно из значений переданного массива
    SomeModel::findOne([1, 2, 3]);
    
    // и так можно
    Url::to(['site/index']);
    
    // и так
    Url::to('images/logo.gif');
    
    // или вот
    $relativeBaseUrl = Url::base();
    $absoluteBaseUrl = Url::base(true);
    $httpsAbsoluteBaseUrl = Url::base('https');
    

    Таких мест в фреймворке очень много. Кого-то это бесит, кто-то считает это API удобным.
    Но если мы хотим использовать тайпхинтинг, все это удобное API превращается в тыкву.


    Qiang так и не вернулся


    Полтора года назад на форуме Yii подняли интересный вопрос, мол, не забил ли Qiang Xue на свое детище?
    Как бы там ни было, с тех пор от него так и не пришло ни одного коммита.


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


    Что в итоге


    Yii — неплохой инструмент и если вам с ним комфортно — отлично.
    В конце-концов, он практичен. Трудно представить задачу, которую невозможно решить, используя Yii.
    Еще Yii невероятно популярен в СНГ. Зная его, очень легко найти как работу, так и сотрудников.


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


    Кроме того, вы всегда можете помочь команде фреймворка. Присылайте внятные баг-репорты, отправляйте пул-реквесты, пишите качественные расширения, помогайте новичкам на форуме и в gitter-е.


    Может быть, Yii еще покажет себя ;)

    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 271
    • +7
      Но стоит ли начинать на нем новые проекты в 2017-м? Я задумался.


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

      Скажем ему большое спасибо и, наверное, распрощаемся.
      • 0

        Какие именно стандарты?

        • 0
          В данный момент семейство общепринятых публичных стандартов для фреймворко-строения у нас одно — это PSR.

          А если идти еще глубже, есть те же принципы SOLID, которые, наверняка, вам прекрасно известны.
          • +3

            Про PSR в Yii в курсе. Мы участвуем в PHP-FIG и эти самые PSR помогаем писать. Когда Yii 2.0 релизился, многие PSR ещё не были приняты, а после релиза ломать работающий код в минорных версиях — это не наш метод. В следующей мажорной версии PSR будут использоваться более широко. Вот текущее состояние: https://github.com/yiisoft/yii2/wiki/PSR-adoption

            • 0
              В следующей мажорной версии PSR будут использоваться более широко.


              Имхо, уже будет поздно.
              • –3

                Почему?

                • +5
                  Потому что на данный момент скорость развития кодовой базы Yii стремительно отстаёт как от языка, так и от стандартов и других фреймворков.

                  Вам выше уже всё сказали — зачем, к примеру, пилить свой, какой-нибудь к примеру FileSystemHelper, если есть множество готовых, устанавливающихся одной командой composer? А на это тратится безумное количество времени.

                  При этом всём никаких киллер-фич в Yii нет. Ну кроме, разве, явного указания лэйаута для страницы в контроллерах :) Но это уже скорее из разряда «жесть», нежели «фича».
                  • +1
                    Вам выше уже всё сказали — зачем, к примеру, пилить свой, какой-нибудь к примеру FileSystemHelper, если есть множество готовых, устанавливающихся одной командой composer? А на это тратится безумное количество времени.

                    Конкретно FileSystemHelper — только обратная совместимость. Некоторые другие части Yii, которые есть где-то ещё, потому что они получились лучше, чем где-то ещё.


                    Ну и плюс тут вопрос контроля и хрупкости. Вспомните left-pad и npm...

                    • 0
                      Некоторые другие части Yii, которые есть где-то ещё, потому что они получились лучше, чем где-то ещё.

                      Даже без сарказма.
                      Можно узнать о этих некоторых других вещах?

            • +4
              а после релиза ломать работающий код в минорных версиях — это не наш метод.

              Реальность показывает иное.
              • –5

                Бывают исключения.

            • +2
              Там вроде из принятых только PSR-3 не соответствует
        • +1
          Yii хорошо соответствует требованию нашего рынка — не все готовы платить за DDD и Symfony, и нужно это далеко не везде, и в принципе для заказчика в конечном итоге в основном пофигу что под капотом, а проектов серьёзного уровня с серьёзным подходом в соотношении со средними и небольшими гораздо меньше.
          • +7
            Yii хорошо соответствует требованию нашего рынка — не все готовы платить за DDD и Symfony, и нужно это далеко не везде


            Можно я перефразирую немного?

            «Не все готовы платить за нормальных программистов, поэтому нанимают людей, не способных разобраться в простейших концепциях программирования, ведь им можно платить меньше — и пофигу на результат.»

            Кажется, что так смысл будет выражен точнее :)
            • +4
              А для клиента который ни в зуб ногой, что нормальный, что не нормальный программист — выглядят одинаково.
              Они могут и не видеть этого программиста — они идут в студию и их встречает менеджер.
              • –1
                Я не знаком с внутренним миром студий и сайтостроения, извините.
                • +2
                  выглядят одинаково.

                  Если мы говорим про сайты визитки — то да. Но обычно когда клиент у вас просит что-то подправить а у него отламывается функционал и вообще все медленно пилится — он может ужа начинать что-то подозревать.

                  • +2

                    Только это, скорее, про тесты и архитектуру, а не про фреймворки...

                    • +2
                      Это, скорее про принципиальную возможность писать бизнес-логику в afterSave(), чем разумеется, большинство «студий» с огромной радостью пользуется.

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

                      И да, это, конечно же, про архитектуру. Только зачем эта архитектура заложена в фреймворк?
                      • +7

                        Принципиальная возможность напихать логику куда угодно есть в каком угодно фреймворке. Это не означает, что её туда необходимо пихать...

                        • 0
                          Расскажите мне, как в концепции request -> [middleware] -> response и при неактивных моделях данных я могу напихать что-то «куда угодно»?
                          • +3

                            Неактивные — это entity с репозиторием? Ну, в репозиторий, очевидно, напихать.


                            А так, например, можно устроить beforeSave() в той же Doctrine. Не раз видел:


                            /**
                             * @PrePersist
                             */
                            public function beforeSave()
                            {
                                // колбасим
                            }
                            • +3
                              Экзотичный пример, конечно, но принимаю :) Что-то ржу )))

                              Не видели никогда, к примеру, вот такое поделие: http://punbb.ru/?
                              Сферические events в вакууме. Event-driven architecture!

                              Я к тому, что бесконтрольным использованием системы событий можно убить любой фреймворк. Абсолютно любой.
                              • 0

                                К сожалению, с event-driven системами работать приходилось :(

                              • +2
                                <zanuda>
                                s/persist/flush/
                                </zanuda>


                                Большая разница в том, что в Yii можно тут сделать что угодно, имея в прямом доступе все компоненты системы через статику, а при работе с symfony+doctrine вы сможете обращаться только к доменной логике (логике модели и ее связей)
                                • +1

                                  Ох, опять ужас придётся копи-пастить:


                                  global $kernel;
                                  $assetsManager = $kernel->getContainer()->get('acme_assets.assets_manager');‏

                                  Но что в Yii это сделать в разы легче — факт.

                                  • +3
                                    Ну, тут очевидная разница в том, что ваш пример — это глобалы, за которые в приличных конторах бьют линейкой по рукам, и это надо сделать специально, а в Yii — это by design. До глобалов на самом деле не видел, чтобы доходили.
                                • +2

                                  Можно пойти дальше и прокинуть entity manager в сущность и сделать у сущности метод save. Да и доктрина сама по себе не идеал.

                                  • 0
                                    Эта возможность, кстати заложена в доктрине из коробки :)

                                    Тем не менее такой подход гораздо удобней, так как не накладывает никаких ограничений на цепочку наследования. Можно сделать ModelTrait и внедрять его везде где очень хочется
                                    • 0

                                      трейты это goto для ООП. )

                                      • Если не секрет, то почему вы так считаете?
                                        • +6

                                          Для того что бы ответить на этот вопрос стоит для начала разобраться чем плохи эти самые goto и почему они considered harmful. На эту тему рекомендую почитать вот эту штуку: Go To Statement Considered Harmful:
                                          A Retrospective


                                          Если коротко — наши мозги плохо заточены под процессы развивающиеся во времени, мы плохо их прокручиваем в голове. В идеале мы хотим чтобы поток управления кодом шел в том же порядке, в каком он и написан. С goto мы вынуждены "прыгать" по исходникам вверх-вниз дабы собрать всю картину и разобраться "как это работает" или "а где проблема".


                                          Тут следует заметить что существуют задачи где goto прекрасно ложатся на ментальную модель выполнения кода — конечные автоматы. Там они очень даже упрощают и реализацию и понимание происходящего. Потому goto не зло, зло это применение их просто так.


                                          Как ответ на эту проблему появилось структурное программирование, которое дает возможность заменить goto на управляющие структуры — if/for/while и тд. Затем появились классы и модули (Simula и Modula) которые вводили новые штуки для получения "структур" для декомпозиции системы. Далее Аланы Кеи и друзья решили развить идею в сторону actor model и сотворили smalltalk, где приложение представлено как децентрализованный граф объектов обменивающихся сообщениями. Сегодня самый близкий этой идее язык из тех что я знаю — Erlang.


                                          Так вот, если мы посмотрим на трэйты — они не влияют на типы объектов. То есть, если упрощать, это тупая копипаста кода. То есть код вы может быть и вынесли в трейт, но он по сути принадлежит тому типу, где используется. И если у вас 10 типов используют 1 трейт, это значит у вас нарушена декомпозиция в 10-ти местах.


                                          Тут опять же стоит заметить что проблемы с трейтами возникают только тогда, когда в них хранится поведение. Тупой код-бойлерплейт не влияющий на поведение объекта прекрасно ложится на ООП. А вот когда у нас поведение плохо декомпозировано и оно вылазит в трейты, это создает ту же проблему что и goto. Только если с goto у нас проблемы во флоу управления, то с трейтами — в управлении зависимостями.


                                          Что бы составить полностью картину как работает объект и его поведение нам приходится прыгать по коду. И чем больше трейтов — тем сложнее. Намного выгоднее будет просто разделить это все на отдельные объекты, воспользоваться прокси-объектами и т.д. Трейты тут все еще могут быть полезны как промежуточный этап при рефакторинге например, но только что бы ускорить процесс. В конце этого процесса трейты с поведением должны быть удалены.

                                          • Понятно, то есть все-таки нет прямой связки между goto и трейтами, а есть лишь подобие в некоторых случаях. Плюс к упомянутому вами выносу всяких вещей, которые не реализуют логику, есть вариант, когда не 10 классов используют 1 трейт, а наоборот, один класс, в зависимости от разных ситуаций его применения, использует 10 трейтов. Например, есть класс, реализующий логику отправки неких данных из одного API в несколько других, и каждое использование этого класса проводится как наследование от базового и включение в себя некоего трейта для того или иного API. Понятно, что это можно реализовать и иначе, но иногда проще и понятнее именно так.
                                            • 0

                                              аналогия прямая: использование goto прямо, грубо (как еще сказать) нарушает процедурную модель так же, как использование trait — объектную модель. использовать их стоит ровно с той же предусмотрительностью что и в случае goto.

                                              • 0
                                                Осталось запретить директиву include в Си, и будет полное объектно-ориентированное счастье на всей Земле :)
                                              • Как вам выше верно и заметили, осталось весь код теперь писать в одном файле и будет счастье. В общем — нет уж, извините, но аналогия далеко не прямая и полная.
                                                • +1

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

                                                  • Если я верно понимаю, что вы пишете, то вы просто зациклились на использовании трейтов как некоем общем коде для некоторых классов или других вещей. Но это же не так.
                                                    • 0

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


                                                      а смысл раскрыт и в первом моем посте и детальнее во-втором. трейт — это хак объектной модели и использовать его только как-то ad-hoc

                                                      • Трейт — это хак файловой системы, когда проще разнести логику по файлам. Не более.
                                                        • 0
                                                          хак файловой системы

                                                          Вы дробите проект по файлам или классам? Тот факт что у вас из-за PSR-2/PSR-4 имя класса привязано к файловой системе — это лично ваш выбор. PHP сам по себе вас в этом не ограничивает. Так что трейты к файловой системе никакого отношения не имеют.


                                                          Трэйты — это способ устранения дублирования кода каших классов. Как минимум потому что использоваться они могут только в контексте классов а не просто файлов.


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


                                                          Просто задумайтесь. Если вы не согласны — просто приведите мне примеры где вы считаете "по другому никак" или даже "по другому неудобно". И тогда будем конструктивно обсуждать.

                                                          • 0

                                                            Трейты удобны для базовых реализаций интерфейсов, прежде всего общего назначения типа ArrayAccess. Множественного наследования нет же.

                                                            • –1

                                                              В Java 8 это решено элегантнее — там есть default methods в интерфейсах.

                                                              • 0
                                                                В шарпе вроде с 7 версии тоже. Но что это за интерфейс содержащий дефолтную реализацию?
                                                                • 0

                                                                  Интерфейс не содержит :) Но если интерфейс реализуют десятки классов и у 90% реализации одинаковые, то трейты удобнее. Например, различные виды сериализации. Или нестандартные для объектов методы доступа. Итеративность. Событийность. Много всего, что не относится к бизнес-логике.

                                                                  • 0
                                                                    Но если интерфейс реализуют десятки классов и у 90% реализации одинаковые, то трейты удобнее.

                                                                    Чаще просто что-то не так с декомпозицией и вот эти 90% должны быть в другом классе. Не всегда, но в большинстве случаев когда применяют трейты.


                                                                    Те же дефолтные реализации методов в java появились как следствие решения проблем обратной совместимости, нежели концепт без которого прям нельзя жить.

                                                                  • 0

                                                                    Вот, кстати, не знаю, зачем это надо в языках, где есть generic-и. В php я пары "интерфейс-трейт" использовал как "дженерики для бедных".

                                                                    • 0

                                                                      В таком случае рекомендую почитать например эту заметку.


                                                                      tl;dr


                                                                      Suppose Java 8 is out and has lambdas. Now you would like to start using lambdas and the most obvious use case for that is to apply a lambda to every element of a collection.

                                                                      The forEach isn’t declared by java.util.List nor the java.util.Collection interface yet. One obvious solution would be to just add the new method to the existing interface and provide the implementation where required in the JDK. However, once published, it is impossible to add methods to an interface without breaking the existing implementation.
                                                                • 0

                                                                  Ну та же идея что и у дефолтных методов интерфейсов в java. Убрать тупой бойлерплейт не влияющий на поведение реализации.

                                                          • 0
                                                            использовании трейтов как некоем общем коде для некоторых классов или других вещей. Но это же не так.

                                                            а как же? это их собственно основная идея.

                                                        • 0

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

                                                      • 0
                                                        прямой связки между goto и трейтами, а есть лишь подобие в некоторых случаях.

                                                        Вы знакомы с таким словом как "аналогия"? Трейты усложняют восприятие кода за счет того что ломают информацию о зависимостях и скрывают проблемы декомпозиции. goto усложняют восприятия кода за счет того что ломают поток управления кодом и скрывают изменения стэйта.


                                                        То есть и то и то — не зло, но при неправильном использовании можно закончить с весьма сложным и запутанным кодом. goto мы худо бедно за 40 лет перестали писать (хотя люди все еще в коде бывают ставят break 2;) а вот в декомпозицию как не умели так и не умеем.

                                                        • +1
                                                          Понятно, что это можно реализовать и иначе, но иногда проще и понятнее именно так.

                                                          вот приведите пример когда это проще и понятно и будет предметный разговор. Мой опыт подсказывает что это практически никогда не удобнее и не понятнее и даже если у вас получилось понятно — несколько чейнжж реквестов и коду становится плохо.

                                                    • 0
                                                      не хватает таблички «сарказм»…
                                                    • 0

                                                      лучше взять ProxyManager и реализовать все это добро проксей. Но это тогда уже не active record получится.

                                                      • 0
                                                        Не согласен с вами.
                                                        Трейт это те же mixin, тоже самое свойство и тоже самое наследование. Если ваша декомпозиция использует наследование, то трейты тут не могут быть причиной неверной декомпозиции: )
                                                        • 0
                                                          Трейт это те же mixin, тоже самое свойство и тоже самое наследование.

                                                          ни разу.


                                                          Если ваша декомпозиция использует наследование

                                                          как редкое исключение, чаще агрегацию. В целом за последний год были два-три раза когда наследование было единственным адекватным решением проблемы в контексте вопросов декомпозиции и в целом кода.

                                          • +3

                                            Согласен, но тогда для yii остается место только в качестве read model. Меня лично больше смущает страсть сообщества yii к велосипедам. Это я ничем объяснить не могу. Вот хоть убей.

                                            • +2

                                              Я тоже. Одно дело сам фреймворк — в него компоненты удачные перекочевали из тех времён, когда ничего не было. Плюс некоторые запилили с нуля потому как было время на них и могли сделать хорошо. Итеративно улучшать это всё логично потому как оно не хуже альтернатив. Хотя, конечно, временами некоторые части хочется выкинуть и взять что-то, что их переросло. Но обратная совместимость в 2.0 это сделать не позволяет.


                                              Совсем другое дело — проекты. Вот в них чем руководствуются, реализуя с нуля всякое, я не уверен...

                                              • +3

                                                что из этого продиктовано обратной совместимостью?
                                                https://github.com/yiisoft/yii2-queue — лежало несколько месяцев недоделанное, потому что никто не допиливал базовую итерацию.
                                                https://github.com/yiisoft/yii2-authclient — несколько месяцев никто не трогал нерабочую интеграцию с твиттер
                                                https://github.com/yiisoft/yii2-collection — свеженькие коллекции. фейспалм
                                                https://github.com/yiisoft/yii2-httpclient — качество ужасное, но комбайн в стиле yii
                                                https://github.com/yiisoft/yii2-shell — думаю, это тебе самому хотелось поделиться игрушкой, которую сделал. Не уверен, что ей вообще место под yiisoft.

                                                • 0

                                                  Из этого ничего :)


                                                  • queue — фреймворконезависимых очередей нормальных не нашлось. Запилили прототип на хакатоне потому что было интересно, сможем ли. Прототип Журавлёв допилили до прекрасного состояния и расширение мы приютили. При этом он его развивает, мы только помогаем советами и докой, как и помогали пока репозиторий был в его аккаунте. Времени не кушает.
                                                  • authclient был с самого начала. Он прилично интегрирован с аутентификацией. Если бы использовали внешнюю либу для OAuth, так и так пришлось бы обёртку делать.
                                                  • collection — сильно просили прямо в фреймворке сделать поддержку. Решили сделать в расширении. Это не просто generic-коллекции, там есть и специфичные для AR Yii штуки, которые позволяют работать с базой довольно эффективно, а не вытягивать всё и фильтровать средствами PHP.
                                                  • httpclient — обёртка с двумя простейшими дефолтными драйверами. Нужна чтобы, например, можно было бы подменить Guzzle на что-то ещё.
                                                  • shell — да, скорее всего так. Но каши не просит, можно и оставить.
                                                  • +1
                                                    SamDark
                                                    httpclient — обёртка с двумя простейшими дефолтными драйверами

                                                    Вы забыли уточнить с 2-мя уж очень неудобными и деревянными драйверами. Простые задачи он решает, стоит столкнуться с доп контролем — и все, наследуешься и сам реализуешь методы.

                                                    Чем вас Guzlle не устроил, не понимаю, зачем вам свой велосипед? Лучше он все равно, как показала практика, не поедет.
                                                    • –1

                                                      Guzzle не устроил интерфейсом. Есть проект. В нём есть зависимости. Одна зависимость использует Guzzle, вторая — httplug, третья ещё что-то. В итоге у нас натягивается много либ. Если зависимости используют httpclient вместо всего этого, появляется возможность вытаскивать одну либу и собирать только её баги.


                                                      p.s. да, PSR-7 сейчас эту проблему решает, но тогда его не было...

                                                      • +4
                                                        каши не просит, можно и оставить.

                                                        про это и был упрек — у вас все каши не просит, что нужно и что не нужно.


                                                        да, PSR-7 сейчас эту проблему решает, но тогда его не было...

                                                        это не так. Напомню, что я несколько раз высказывался о недоумении об отсутствии поддержки psr-7 в http-клиенте, даже в рамках issue на гитхабе, после чего выяснилось что Paul Klimov о PSR-7 ни сном ни духом.
                                                        PS Дата релиза PSR-7 и первого коммита http-клиента расходятся на 2 месяца, т.е. но уже был в релизе, но даже до релиза он пребывал в стабильном состоянии как минимум год, и поверх него было реализовано куча продуктов (например первый коммит zend diactoros был за 9 месяцев до релиза).


                                                        Guzzle не устроил интерфейсом. Есть проект. В нём есть зависимости. Одна зависимость использует Guzzle, вторая — httplug, третья ещё что-то. В итоге у нас натягивается много либ.

                                                        так теперь этим третьим "чем-то" будет yii2-http-клиент, и в проекте скоро появится что-то четвертое.

                                                        • 0
                                                          так теперь этим третьим "чем-то" будет yii2-http-клиент, и в проекте скоро появится что-то четвертое.

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


                                                          Оно, конечно, видно, что сейчас можно просто завязаться на интерфейсы PSR-7 и deprecate-нуть httpclient на версию 2.1. Вероятно, так и сделаем.

                                                    • 0
                                                      фреймворконезависимых очередей нормальных не нашлось

                                                      допилить до нормального состояния bernard или enqueue.


                                                      фреймворконезависимых

                                                      "yiisoft/yii2": "~2.0.10",

                                                      • +1

                                                        угу. вместо того, чтобы сделать поверх queue-interop

                                                        • 0

                                                          Что такое queue-interop? Это? https://github.com/queue-interop/queue-interop с 200 инсталлами и 20 звёздочками?

                                                          • +2

                                                            да, и это хорошая инициатива сделать фреймворконезависимые очереди, недавно выделенная из https://github.com/php-enqueue < — вот это фреймворконезависимые очереди, а не yii2-queue

                                                            • 0

                                                              Я и не говорил, что yii2-queue фреймворконезависимый. Я говорил, что мы не нашли чего-то, что можно было бы взять за базу.

                                                          • 0

                                                            А вообще почему бы и нет? Если есть свободное время — ждём pull request, который добавит совместимость с интерфейсами queue interop.

                                                            • +1

                                                              не надо велосипедить уже готовое решение — нужно проинтегрировать с yii2 уже готовые php-enqueue, имхо

                                                              • 0
                                                                Об этом Cэм и пишет. Проинтегрируйте и оформите pull request.
                                                                • 0

                                                                  добавить совместимость с интерфейсами и проинтегрировать готовое — вещи разные.

                                                                  • 0
                                                                    1. Совместимость.
                                                                    2. Выкидываются свои бэки, заменяются готовым.

                                                                    Что не так?

                                      • –20
                                        php фреймворки обрасли ненужной логикой и всякой всячиной, что со стороны смотреть на все это дело сложно, не говоря уже, о том, чтобы что-то на нем написать.
                                        Я благополучно слез с этой сложной машины на легковесный node js
                                        • +24
                                          на легковесный node js

                                          Поперхнулся…
                                          В течении последних двух лет назвать js легковесным…
                                          Слезть с php на ноду из-за легкости — месье знает толк в извращениях.

                                          • 0
                                            php фреймворки обрасли ненужной логикой и всякой всячиной, что со стороны смотреть на все это дело сложно


                                            quod erat demonstrandum
                                            • +1
                                              Node.js в крупном приложении обрастает тьмой модулей и в итоге все равно получается некий кастомный фреймворк со сложной логикой. И эта логика по сложности не уступает логике многих PHP фреймворков «из коробки». А если взять какой-либо «упрощенный» PHP фреймворк, вроде Silex или Slim, то можно изначально получить менее «сложную машину».
                                            • +3
                                              Оба пути ведут в никуда.

                                              Что-то не смог прочитать «между строк» про пути выхода…
                                              • +20

                                                Неплохой пост. Частично верный, частично нет. Думаю, стоит немного разобрать.


                                                Архитектура фреймворка


                                                Выходит, архитектура закладывалась в 2014 — 3 = 2011-м году. Или раньше?

                                                Архитектура закладывалась в течение многих лет. Что-то, что показало себя хорошо — перекочевало в немного изменённом виде ещё из Prado, что-то из Yii 1.1, а что-то, что показало себя плохо — было обдумано и разработано с нуля.


                                                Мысленно вернемся в 2014-й. Ожидание второй версии Yii кажется бесконечно долгим, core-разработчики не называют никаких сроков. Разработка ведется в закрытом от публики репозитории.

                                                А вот и нет: https://habrahabr.ru/post/178917/


                                                С первой версии нам достались глобальные константы в коде, свой autoloader, своя хитрая система алиасов для файлов и папок.
                                                Ооооок. Просто напоминаю, что сейчас идет вторая половина 2017-го.

                                                • Константы — да. Будем менять их на getenv или что-то подобное.
                                                • Не понимаю, что плохого в своём полностью PSR-4 совместимом autoloader-е, необходимом для поддержики алиасов и работающем быстрее, чем тот же autoload-ер Composer-а. Если бы он было хуже, тогда нет вопросов — выкинули бы не думая. Напомню, что писался он задолго до релиза Composer. И ещё уточню, что autoload-ер в Yii 2 не имеет ничего общего с autoload-ером Yii 1.1.
                                                • Что плохого в системе алиасов для путей файловой системы и URL тоже не понимаю.

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

                                                Конечно, зависит от опыта, но знакомые, которые писали на Yii проекты и до этого работали с Symfony, Django, RoR, Spring и т.д. сильных проблем не испытывали. Незнакомый код не в счёт. Изучение при использовании нового инструмента всегда занимает какое-то время. Любой фреймворк даёт надстройку над языком. Свой DSL, упрощающий построение проектов. Иначе какой в фреймворке смысл?


                                                Компоненты, их события, поведения… возможно, они имели смысл в PRADO Framework, где "компонентами" были TButton, TAccordion и все вот это.

                                                Они и сейчас имеют смысл. Да, иерерхия наследования в Yii далеко не идеальная и мысли по сокращению её есть.


                                                Среди достоинств Yii часто озвучивают простоту фреймворка. Но это правда только отчасти. Знаете, что происходит, когда вы делаете что-то безобидное вроде $post->title = 'Hello'?
                                                Вы можете побывать здесь, здесь, здесь, здесь, а также в любом прикрепленном к $post event-у или behavior-у. Это может свести с ума во время отладки.

                                                Только если кто-то очень сильно постарается в коде приложения и либо нацепляет очень много нетривиальных behavior-ов, либо сделает всё на событиях. Логика properties очень простая, покрытая на 100% тестами и хорошо документированная.


                                                Не добавляет радости и тот факт, что любой компонент приложения из любого места можно достать через Yii::$app. Эдакий экземпляр приложения и сервис-локатор в одном лице.

                                                Практически в любом фреймворке можно достать глобально и явно контейнер. Но это не означает, что по-другому писать нельзя (в Yii, например, есть нормальный autowiring) и это не означает, что так надо делать.


                                                DI-контейнер


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


                                                Внутри Yii 2 собственный контейнер не используется, а все компоненты лежат в Yii::$app, прямо как в первой версии.

                                                Используется. Поэтому возможно, например, вот это: http://www.yiiframework.com/doc-2.0/guide-concept-di-container.html#practical-usage


                                                Вот автовайринга в ядре нет. Потому что во-первых — рефлексия, а во-вторых — при чрезмерном использовании отладка лазанья-кода с ним действительно превращается в ад.


                                                Active Record


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

                                                Хотели переиспользовать — нечего было бизнес-логику завязывать на работу с базой… если её запихать, например, в entity из Doctrine, которые вроде отдельные, а вроде и с метаданными в виде тучи аннотаций — лучше не будет. Хотите чистого кода — выделяйте его в отдельный слой. Да, это не просто, но одинаково не просто при использовании чего угодно потому как от фреймворка не зависит.


                                                Фронтенд


                                                Для установки Yii 2 вам нужно в принудительном порядке поставить глобально fxp/composer-asset-plugin, для того, чтобы поставить jQuery c помощью composer-а, для того, чтобы установился Yii.

                                                Со следующего релиза 2.0 уже нет. И долго ждать тоже не нужно. Хотя да, использовать fxp было рисковым предприятием и косяков вылезло много.


                                                jQuery входит в обязательные зависимости Yii 2.

                                                Пока да.


                                                Если знаете, как поставить Yii без возни с ненужными фронтенд-пакетами — пишите в комментариях.

                                                https://github.com/cebe/assetfree-yii2


                                                Все остальные компоненты


                                                Абстракция над HTTP, кеширование, логирование… они есть, и они без проблем выполняют свои задачи.
                                                Конечно же они самобытные, гвоздями прибитые к Yii, и не имплементируют соответствующие им PSR-ы.

                                                Уже писал в комментах, но повторю. Во первых, это не совсем так: https://github.com/yiisoft/yii2/wiki/PSR-adoption
                                                Во-вторых, некоторые PSR ещё не были приняты на момент релиза 2.0 и ломать обратную совместимость сразу после их принятия было ни к чему.


                                                Будущее Yii


                                                Код, написанный на PHP, работает везде, а код, написанный на Yii — только на Yii. Вы либо ставите на Yii всё, либо ничего. Это риск для долгосрочного проекта.

                                                В чём именно риск, поясните.


                                                Конечно, приложив усилия, можно писать framework-agnostic код и разруливать все через DI-контейнер, но это не поощряется.
                                                Если вы все-таки решитесь на это, вам прийдется забыть про Yii-вский ActiveRecord или начать писать неприлично толстые прослойки между фреймворком и вашей бизнес-логикой.
                                                Но это, мягко говоря, неоправданно.

                                                Не понял, при чём там ссылка на issue, созданный членом команды Yii, где нет ни слова про DI.
                                                И ещё не понял, почему это я не могу взять, например, независимый Facebook SDK и использовать прекрасно в Yii, внедрив его в конструктор сервиса через autowiring?


                                                Если вы наследуете какой-либо класс своего приложения от любого другого класса Yii, без Yii вы его работать не заставите, ведь он обязательно наследует Object или Component. Вот.
                                                Даже если вы вытащите вместе с ним весь ворох родительских классов и реализуемых интерфейсов, это вам не поможет.

                                                Аргументы из серии "а вдруг мне после трёх лет разработки проекта нужно будет поменять фреймворк" — они про коней и вакуум. Такого быть не должно. Если такое есть, в проекте что-то фатально не так.


                                                С модными нынче DDD и CQRS/Event Sourcing Yii также вам не помощник. Скорее, даже будет вставлять палки в колеса.

                                                С DDD tactical вам мало что из современных фреймворков поможет. Палки Yii в колёса не вставляет, если вы знаете, как готовить DDD.


                                                Команда фреймворка всё пишет сама. Даже VarDumper они написали свой, а не взяли из компонентов Symfony.

                                                Потому что компонентов Symfony тогда ещё не было. Отказаться от всего, что мы написали просто потому, что есть альтенатива у другого фреймворка — не лучшая идея, особенно если наш код не хуже и поддерживать его не составляет проблем.


                                                Регулярно поддерживать и улучшать столько компонентов — очень непростая задача для небольшой команды. И у этой команды есть два пути.

                                                Во первых, можно оставить все как сейчас.
                                                Все компоненты пишем сами. Сильная связанность. Полностью изолированная экосистема фреймворка. Небольшое уютное комьюнити. Медленная деградация.

                                                Во-вторых, можно все-таки разбить монолитный Yii на независимые от фреймворка компоненты.
                                                Но тогда это будет уже не Yii с простым и удобным API, а просто еще один набор компонентов, не востребованный вне экосистемы Yii.

                                                Оба пути ведут в никуда.

                                                Вот только пути не два и не обязательно пускаться в крайности. Например, можно пойти по пути Laravel — выкинуть всё своё, взять за базу компоненты Symfony, написать к ним обёртки и допы. Часть кода можно выделить в библиотеки. Тот же слой i18n у Yii один из самых мощных, так что за востребованность можно не беспокоиться. Или можно часть кода выделить в расширения и подключить к их поддержке и разработке заинтересованных людей. Это уже сделано с ElasticSearch, Docker и очередями и такой подход показывает себя неплохо.


                                                PHP 7


                                                Но если мы хотим использовать тайпхинтинг, все это удобное API превращается в тыкву.

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


                                                Qiang так и не вернулся


                                                Самые внимательные заметили отсутствие через пять месяцев. Это означает только одно — даже если "грузовик передет" ещё одного члена core team, фреймворк не умрёт.

                                                • 0
                                                  Хотели переиспользовать — нечего было бизнес-логику завязывать на работу с базой

                                                  На самом деле, можно не завязываться на базу даже используя ActiveRecord, если реализация ActiveRecord такое позволяет.


                                                  Всю работу с базой можно вынести в репозитории и сделать вид, что AR-методов больше нигде нет. Какая разница, $fooMapper->find($id) или FooModel::find($id)? А конфигурацию AR можно рассматривать ровно как доктриновские аннотации и не считать частью модели.


                                                  Наверное, можно даже сделать прослойку вида
                                                  class Entity extends yii\ActiveRecord {}
                                                  и вынести AR-конфигурацию из моделей в трейты :)


                                                  entity из Doctrine, которые вроде отдельные, а вроде и с метаданными в виде тучи аннотаций

                                                  Doctrine позволяет вынести маппинг в отдельные файлы. Аннотации опциональны. Мне они тоже не нравятся.

                                                  • 0
                                                    А можно использовать в качестве модели сторонний класс, который не унаследован от иерархии актив-рекорд? Доктрина такое позволяет.
                                                    • 0

                                                      Нет, в Active Record нельзя. Сам паттерн создан для обратного. Доктрина — не Active Record.

                                                      • 0
                                                        Ну я это написал к тому, что не завязывать модели на актив-рекорд не получится. Кстати доктрина позволяет организовать ActiveRecord-like работу
                                                        • 0

                                                          Вот только лучше так не делать. Никогда. Лучше подключите к проекту любую популярную реализацию active record если вам так надо, в этом ничего плохого нет. А вот калечить доктрину и использовать ее внутренние механизмы в вашем коде — дело плохое.

                                                          • 0
                                                            В смысле внутренние и почему калечить? Это «изкоробочное» решение, на основе которого можно сделать свои методы активных моделей через какой-нибудь трейт

                                                            Но самому пользоваться еще не доводилось.
                                                            • 0
                                                              В смысле внутренние и почему калечить?

                                                              В том смысле что эта штука юзается по сути исключительно для прокси-классов. Это не часть публичного API.


                                                              Те же prePersist/postPersist тоже не рекомендуется юзать.

                                                        • 0

                                                          Почему не получается? Делайте Model и Repository. Кто мешает?

                                                          • 0
                                                            Я правильно понимаю, что берется сторонний класс, для него делается репозитрий, который наследуется от AR? Но в таком случае разве репозиторий не будет возвращать инстансы самого репозитория вместо модели? или надо будет писать кастомную инстанциацию объектов?
                                                            • 0

                                                              Нет. Ничего не наследуется от AR. Используется либо AR внутри репозитория, либо вообще не используется. Query Builder тоже неплох.

                                                              • 0

                                                                Инстанциацию кастомную надо, да. Что-то вроде https://github.com/samdark/hydrator

                                                                • 0
                                                                  Ну, тогда это уже привет data mapper, но идею понял, спасибо
                                                                  • +1

                                                                    ну до мэппера тут не хватает собственно мэппера. Процесс гидрации он как бы и в AR есть.

                                                                  • 0

                                                                    Довольно бессмысленный перегон данных туда-сюда получается.


                                                                    Я особо не знаком с yii, но я не вижу существенных проблем в подходе типа:


                                                                    abstract class Entity extends \yii\ActiveRecord {}
                                                                    
                                                                    class Foo extends Entity {
                                                                        use FooRecord; // here goes all the yii AR code
                                                                    
                                                                        public function myDomainMethod() { ... }
                                                                    }

                                                                    Единственное, что сразу приходит в голову — наверное, с конструктором будут проблемы.

                                                            • 0
                                                              Сам паттерн создан для обратного.

                                                              ну формально этот паттерн создавался для упрощения работы с данными в data-centric приложениях, где даже row data gateway уже оверкил. Но про необходимость наследования никто на самом деле не говорит. Можно например прокси-классы юзать и вуаля. Другое дело что ProxyManager помоложе вашей реализации AR.


                                                              Хотя я хз, как по мне реально на сегодняшний день для вещей где active record нельзя проще через cqrs фигачить, и использовать AR для read model. Хотя для дата мэпперов место еще есть.

                                                              • 0

                                                                Мне кажется, что у rails-подобных AR в качестве read model как раз проблемы.


                                                                Read model — они же такие, зависят от контекста. Скажем, чтобы далеко за примером не ходить, есть хабрапосты, и мне временами надо для них выбрать количество комментариев, а если пользователь авторизован — еще и количество новых. Куда их, пардон, засунуть? В динамические атрибуты, и потом каждый раз гадать, есть ли там что?

                                                                • 0

                                                                  Можно завести две record на одну таблицу в разных namespace-контекстах.

                                                        • +3
                                                          даже если "грузовик передет" ещё одного члена core team, фреймворк не умрёт.

                                                          это только если считать фреймворк живым. После ухода Qiang (а уже прошло время и можно сделать вывод), считавшего фреймворк своим детищем и непосредственно вкладывавшегося в его развитие, продукт стал двигаться в сторону умирающих фреймворков типа codeigniter и cake с некоей своей тусовкой сектантов и вяловатой core-team. Спустя шесть лет после начала разработки, трех лет после релиза и практически моментального морального устаревания только началось обсуждения новой версии. Раньше 2018го ожидать ничего не приходится. И то если это будет патч-релиз, ломающий совместимость в нескольких компонентах. 4 года на одной версии, превращающейся в то, чем стала yii1 на 2013-4 год. 4 года это гигантский срок.
                                                          Ну а сделать кардинально новый релиз как был yii2 по отношению к yii1 современная команда разработки просто не осилит. Боюсь даже грамотно раздербанить монолит на компоненты будет трудной задачей, и это мы не увидим раньше 2019го (если вообще увидим).

                                                          • +1

                                                            4 года — это время жизни нормального проекта. Не каждые же пол года ломать всё и релизить мажорную версию...

                                                            • +1
                                                              Релизный цикл симфони — 2 года, перед выпуском нового мажора выпускают лтс для предыдущей версии. при этом этот LTS находится в «пограничном» состоянии, т.е. в нем обычно работает старый функционал, но кидается депрекейтами и уже работает новый функционал. в x.0 депрекейты выпиливают.

                                                              Т.е. «ломать все» как раз таки необязательно, без проблем пишутся библиотеки, которые поддерживают "~2.7 || ~3.0", а потом, думаю и "~2.7 || ~3.0 || ~4.0".
                                                              • 0

                                                                У Symfony с этим всё хорошо, согласен.

                                                          • +3
                                                            Отстутсвующие фичи из других фреймворков либо настолько редко используются, что никому не нужны, либо просто их никто не просил. Так мы не против допила контейнера, если в этом есть необходимость. Если вам лично нужна какая-то фича, опишите почему в issue и мы вместе подумаем над решением.


                                                            Так в этом и проблема — Yii сообщество не знает, что им нужен нормальный DI, во всех примерах и уроках по Yii ни намека на контейнеры. В основном Yii::$app — это весь DI и в этом и есть весь выстрел в ногу, особенно, когда оно используется за пределами контроллера или команды.

                                                            Когда класс компонента юзает Yii::$app, он начинает мочь всё и вся, он перестает быть прозрачным и любой потенциальный юнит тест на него скорее всего бесполезен, ибо, например, замокать зависимость класса, которая юзается в компоненте через Yii::$app — не, ну никак.

                                                            Но сколько не спрашиваю, мало кто из Yii разработчиков этим обеспокоен и 99% просто не знают о mock\stub.

                                                            Данный фреймворк дает возможность делать всякую бяку из коробки, у него самый ужасающе низкий порог вхождения. И поэтому подавляющее большинство разработчиков максимально неопытны и формируют вредные взгляды о PHP cообществе в целом.
                                                            • +2

                                                              Порог действительно низкий. Это так.


                                                              Вы хотите, чтобы на PHP были либо опытные продвинутые разработчики, либо никого? Я нет потому что тогда сильным проектам, где эти продвинутые разработчики нужны, будет неоткуда вырастать.


                                                              Yii допускает много вольностей. На нём можно быстро фигачить, а можно писать грамотно и хорошо. Зависит от опыта и дисциплины того, кто пишет.

                                                          • 0
                                                            Меня лично всего меня вымораживает то, что все встроенные валидаторы требуют, чтобы проперти были не ниже, чем protected, иначе ни публичного доступа нет, ни встроенные __get __set до них не доберутся
                                                            • 0

                                                              Поясните, как вы хотите получить публичный доступ к private?

                                                              • 0
                                                                Идеальный ответ — никак. Я бы хотел наложить валидатор на метод в таком случае.

                                                                Если простым путем — через рефлексию

                                                                Если универсально, то вот https://symfony.com/doc/current/components/property_access.html, штука сама выберает, как обратиться к свойству, через метод, магию или публичный доступ
                                                                • 0

                                                                  В Yii вы можете навесить валидатор на соответствующий приватному свойству геттер. А вообще валидировать приватные свойства не в конструкторе и не в сеттере несколько странно.

                                                                  • 0
                                                                    А можно пример? Это какие то отдельные валидаторы? или работает через магический геттер? Потому что в коде по ссылке выше идет прямое обращение к атрибуту
                                                                    • 0

                                                                      Через магический геттер.

                                                                      • 0
                                                                        ну, магический — это не совсем «соответствующий приватному свойству». Например, если оперировать терминами той же доктрины, то в свойствах связей toMany лежит обычно Collection, а геттер отдает массив для того, чтобы нельзя было эту коллекцию мутировать.

                                                                        ясно, спасибо
                                                            • 0
                                                              А вот и нет: https://habrahabr.ru/post/178917/

                                                              Да, насчет сроков могу ошибаться


                                                              PSR-4 совместимом autoloader-е, необходимом для поддержики алиасов
                                                              Что плохого в системе алиасов для путей файловой системы

                                                              То, что для ее поддержки пришлось писать свой автолоадер?
                                                              В итоге теперь мы оперируем и неймспейсами и алиасами. Алиасы для ФС выглядят как вынужденное наследие Yii 1, а не фича.


                                                              В чём именно риск, поясните.
                                                              Аргументы из серии "а вдруг мне после трёх лет разработки проекта нужно будет поменять фреймворк" — они про коней и вакуум

                                                              Речь конечно идет не о проектах.
                                                              Например, мы работаем в компании, где пишутся продукты с более-менее похожей кодовой базой. Функционал можно и нужно переиспользовать.
                                                              Выделяя модули/расширения Yii-шного приложения в отдельные пакеты, мы на много лет вперед привязываемся к текущей мажорной версии Yii. Либо вынуждены писать максимально абстрагируясь то Yii, что очень непросто.


                                                              Например, можно пойти по пути Laravel

                                                              Будет интересно услышать от вас планы по развитию фреймворка.


                                                              даже если "грузовик передет" ещё одного члена core team, фреймворк не умрёт

                                                              Это здорово и правильно. Просто странно, что Qiang ушел так незаметно. Если не секрет, кто сейчас решает стратегические вопросы?

                                                              • +2
                                                                То, что для ее поддержки пришлось писать свой автолоадер?

                                                                Нас, кроме алиасов, интересовала ещё и скорость загрузки классов. На момент релиза Yii лодер Composer-а был совсем плох в этом плане. issue на тему loader-а практически не было, работает всё стабильно, каши не просит.


                                                                В итоге теперь мы оперируем и неймспейсами и алиасами. Алиасы для ФС выглядят как вынужденное наследие Yii 1, а не фича.

                                                                Алиасами мы для загрузки классов не оперируем. Как и не оперируем неймспейсами для работы с файловой системой.


                                                                Выделяя модули/расширения Yii-шного приложения в отдельные пакеты, мы на много лет вперед привязываемся к текущей мажорной версии Yii. Либо вынуждены писать максимально абстрагируясь то Yii, что очень непросто.

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


                                                                Будет интересно услышать от вас планы по развитию фреймворка.

                                                                Эволюционные. Будем облегчать ядро, избавляться от всяких jQuery, выкидывать версии PHP до 7-ки, выкидывать HHVM. Выпиливать части в расширения и независимые библиотеки, которые, по возможности, будут поддерживаться заинтересованными разработчиками. Облегчать дерево наследования и стремиться выпилить его совсем...


                                                                Революции вроде 1.1 → 2.0 не хочется. По крайней мере пока.


                                                                Если не секрет, кто сейчас решает стратегические вопросы?

                                                                Я, Carsten Brandt, Дмитрий Науменко, Климов Павел, Boudewijn Vahrmeijer.

                                                                • +1
                                                                  Так этот факт не меняется вне зависимости от используемого фреймворка. Писать независимые компоненты сложнее, чем завязанные на другой код.


                                                                  Вот это совсем неправда. Вам говорят о том, что сложно писать модули в Yii, не привязанные к Yii. А не вообще к любому коду.

                                                                  В симфони очень легко пишется независимая библиотека, к которой рядом (сверху) кладется бандл, семантическая конфигурация и расширение для DI. За примерами далеко ходить не надо — JmsSerializer + JmsSerializerBundle, DoctrineOrm + DoctrineBundle и тд. Делается очень просто все.
                                                                  • +1

                                                                    Так и в Yii можно так же. DI контейнер в фреймворке вполне себе универсальный и может настраивать не только классы самого фреймворка.


                                                                    Также посмотрите на обилие прослоек, коннекторов и обёрток для независимых библиотек, реализованных в виде extension-пакетов.

                                                                    • 0
                                                                      Ну насколько я понимаю, суть претензии выше в том, что для того, чтобы интегрировать внешний код в Yii, приходится как раз таки эти обертки, прослойки и коннекторы реализовывать, просто чтобы подключить библиотеку. В симфони в принципе достаточно только описать класс для DI, а с версии 3.3 уже иногда и это можно не делать (для простых случаев).
                                                                      • 0

                                                                        Да не, не приходится. Отлично всё конфигурируется либо через контейнер, либо по месту. Просто люди привыкли делать обёртки ещё с 1.1 и по инерции наделали их очень много...

                                                                  • 0

                                                                    Спасибо.


                                                                    Будем облегчать ядро, избавляться от всяких jQuery, выкидывать версии PHP до 7-ки, выкидывать HHVM. Выпиливать части в расширения и независимые библиотеки, которые, по возможности, будут поддерживаться заинтересованными разработчиками. Облегчать дерево наследования и стремиться выпилить его совсем…
                                                                    Революции вроде 1.1 → 2.0 не хочется. По крайней мере пока.

                                                                    Если честно, звучит как переход в стадию поддержки.

                                                              • +3
                                                                Могу написать только одно.
                                                                Yii2 ускоряет и упрощает разработку, но, гавнокода становится больше!
                                                                Например на том же Phalcon, Laravel и т.д. разработка может идти немного дольше, но компонентность будет сохранена в нормальном виде, и не будет привязки к фреймворку.
                                                                Я за Phalcon and Laravel в долгосрочных и сложных проектах, и Yii2 для срочной разработки и возможно в будущем сложных проектах(с обязательным переносом на новый фреймворк через 2-3 года)
                                                                • +4
                                                                  с обязательным переносом на новый фреймворк через 2-3 года

                                                                  А сразу писать нормально или порефакторить потом никак?

                                                                  • +2
                                                                    Например на том же Phalcon, Laravel и т.д. разработка может идти немного дольше, но компонентность будет сохранена в нормальном виде, и не будет привязки к фреймворку.

                                                                    Да ладно… "компонентность". В Laravel есть десяток способов провалидировать данные с формы, и каждый из них похож на говнокод. Как тут можно удержаться от


                                                                    и не будет привязки к фреймворку

                                                                    Тогда нафига вам фреймворк? Берёте composer, ставите десяток либ и фигачите уникальное сочетание (месиво) компонентов, которое будут изучать каждый новый разраб, пришедший на проект. Уж лучше монолитный фреймворк со всем необходимым функционалом, чем кучу модулей, как в symfony.
                                                                    Ах да. Напомню, что wordpress уязвим из-за сторонних плагинов. Так кто мешает делать дырявые модули для всех фреймворков, пускай и рабочие модули?


                                                                    Я за Phalcon and Laravel в долгосрочных и сложных проектах, и Yii2 для срочной разработки и возможно в будущем сложных проектах(с обязательным переносом на новый фреймворк через 2-3 года)

                                                                    Какой-то не очень долгосрочный проект, если уже через 3 года на новый фреймворк нужно переносить.


                                                                    Я за Phalcon and Laravel

                                                                    Что-то не слышал, чтобы Phalcon развивался быстрее Yii.

                                                                  • +8
                                                                    Наверное заминусуют, но…
                                                                    Yii, вероятно, самый популярный PHP фреймворк на просторах СНГ.
                                                                    Многие годы он был замечательным инструментом и помогал нам зарабатывать на хлеб с маслом.

                                                                    А что вы для него сделали?
                                                                    За symfony и laravel в том или ином виде стоит коммерция, облака, поддержка, сервисы, всякие и проч.
                                                                    yii2 развивается за счет комьюнити и энтузиазма разработчиков и только за это им огромный респект, потому что на хлеб с маслом они помогают заработать очень многим.
                                                                    • +2
                                                                      Разве не правильнее было бы юзать продукт, у которого уже сейчас имеются LTS релизы, ком. поддержка и прочее в проекте, который планирует достаточно долго развиваться?
                                                                      Что мы сделали для Yii, чтобы он стал лучше? А зачем, когда уже сейчас есть Симфони, который во всю финансируют?

                                                                      Тем временем в Yii как известно, один из основных разработчиков ушел в Go.

                                                                      Зачем тратить деньги на доработку Yii, если можно взять Симфони прямо сейчас и быть уверенным в завтрашнем дне и в выходе Symfony 4 Flex в ноябре?
                                                                      • –2
                                                                        Разве не правильнее было бы юзать продукт, у которого уже сейчас имеются LTS релизы, ком. поддержка и прочее в проекте, который планирует достаточно долго развиваться?

                                                                        Angular видел? Каждая версия хрень какая-то. Зато LTS!!!
                                                                        Зачем вам LTS? Вон nodejs 0.12 сколько лет существовал и на нём кучу проектов запилили, и ничего не произошло. Находите баг, пишите issue и всё ок и без всяких LTS. К тому же кто вам мешает сделать исправления самостоятельно? Дебажить не умеем что ли?


                                                                        Зачем тратить деньги на доработку Yii, если можно взять Симфони прямо сейчас и быть уверенным в завтрашнем дне и в выходе Symfony 4 Flex в ноябре?

                                                                        И что вам это даст? Те же возможности писать говнокод, как и везде, те же баги, уязвимости, велосипеды. Ах да!!! Цифра 4 небось привлекает? Тут вспоминается Windows Vista, 7, 8, 8.1, 10. У них то финансирование побольше будет, чем у symfony, а толку 0.
                                                                        Пишите на том, что вам нравиться, а не что финансируется. Как по мне и codeigniter вполне нормальный для разработки, если голова на плечах есть. Ничто не мешает сделать на нём сложный проект с любой архитектурой, было бы желание его в достаточной мере изучить.

                                                                        • +2
                                                                          Ой, сколько восклицательных знаков.

                                                                          Пишите на том, что вам нравиться, а не что финансируется. Как по мне и codeigniter вполне нормальный для разработки, если голова на плечах есть. Ничто не мешает сделать на нём сложный проект с любой архитектурой, было бы желание его в достаточной мере изучить.


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

                                                                          А так сразу вспоминается любимая Коханочка, которая резко и неожиданно прикрылась к чертям собачьим. Вот это была жопка, мало того, что все сразу начали усилинно линять с фреймворка, так еще через какое-то время х*як — https://habrahabr.ru/post/150201/
                                                                          И это не нормальное состояние проекта, за который тебе платят деньги.

                                                                          И про Symfony Flex советую побольше почитать, много интересного на самом деле планируется, симфони практически стало единственным в мире PHP, что достойно внимания.
                                                                          Чисто из интереса, даже и про недавний 3.3 релиз можно почитать, ибо много добавлено плюшек с DI.
                                                                          Т.е. ребята реально работают и делают нашу работу удобнее.

                                                                          P.S:
                                                                          http://school-assistant.ru/?predmet=russian&theme=pravopisanie_tsia_v_glagolax
                                                                        • –1
                                                                          О да.
                                                                          Вот только в Symfony и laravel напихали всего в базовую сборку.
                                                                          А вот нужных компонентов которые используются в 99% нет.
                                                                          Даже взять к примеру grid
                                                                          я смотрю на эти гриды Symfony и laravel и мне хочется блевать
                                                                          • 0
                                                                            • 0
                                                                              Ну если вам кажется, что это отличное решение.
                                                                              И этим удобно пользоваться.
                                                                              Пользуйтесь на здоровья.
                                                                              Но мне вас жалко
                                                                              • 0

                                                                                А что с этим решением не так?

                                                                                • 0
                                                                                  http://docs.sylius.org/en/latest/bundles/SyliusGridBundle/your_first_grid.html

                                                                                  Оооо да.
                                                                                  Это вообщу юзабельно.

                                                                                  А казалось простая задача, сделать грид.

                                                                                  • +1
                                                                                    Пол дня тратить чтобы сделать один грид.
                                                                                    это как-то попахивает гемороем.
                                                                                    • 0

                                                                                      А задача с гридами решается в Yii?

                                                                                      • +2
                                                                                        да, и очень хорошо. Если нужен простой грид (где-нибудь в админке).
                                                                                        вот пример
                                                                                  • 0
                                                                                    Я конечно могу ошибаться.
                                                                                    Но к примеру laravel содержит в комплекте систему для реализации очередей.
                                                                                    Я не уверен что этот функционал юзают все проекты.
                                                                                    А вот теже гриды юзаются во всех проектах.
                                                                                    И где тогда логика?
                                                                                    • +1

                                                                                      С чего вы решили, что гриды используются на всех проектах?

                                                                                      • 0

                                                                                        Очереди — весьма полезная вещь. Если вы, конечно, не хотите заставить пользователя ждать всё то время, пока отправляется почта или генерится какой-то файл, отчёт и т.п.

                                                                                        • +1
                                                                                          А вот теже гриды юзаются во всех проектах.

                                                                                          Такой ваш опыт говорит только о том, над какими проектами вы работаете. Мир богаче, поверьте.


                                                                                          Я никакие гриды (и вообще серверные UI-компоненты) не использовал уже лет 8 (этим занимается фронтенд-фреймворк типа Angular/React/Vue), а вот очереди мне нужны практически в каждом проекте.