Выбираем Yii2 или laravel

    Введение


    Я уже писал подобную статью, но она была очень не полной и не снабженной примерами, поэтому я решил взять вторую попытку и попытаться раскрыть данный вопрос наиболее полно!

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

    Сразу предупрежу вопрос о том, почему не рассматриваем Symfony.
    Дело в том, что Symfony более низкоуровневый фреймворк, который чаще берут для основы в крупных проектах, например таких, как написание собственного фреймворка для разработки. Его в принципе нельзя сравнивать с Laravel и Yii2, так как они используют его компоненты в своих реализациях. Symfony — это очень мощный продукт, позволяющий гибко настраивать практически любую систему под потребности, но в нем мало чего можно использовать в качестве готовых решений для мелких типовых задачек. На GitHub можно встретить множество библиотек или расширений написанных для того же Yii2 или Laravel как раз на Symfony.

    Yii2


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

    Плюсы


    • Легко изучается, низкий старт разработки
    • Имеет множество встроенных решений для интерфейсов
    • Отличный генератор моделей, контроллеров И CRUD

    Минусы


    • Не очень гибкое формирование роутов
    • Плохо развивается (выход новых версий)
    • Слишком склеенные библиотеки для frontend'а с backend'ом

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

    Легко изучается. Фреймворк действительно легко изучается, и посидев день два, над небольшим проектом, вы уже начинаете спокойно кодить на нем. Для начала изучения маловато хорошей литературы на русском языке, но это хорошо компенсируется благодаря хорошему справочнику на английском. В крайнем случае Google-переводчик. Сейчас обрадую, так было раньше. Совсем недавно, они обновили свой сайт с гайдами и документацией, и теперь есть гайды на русском языке, находятся они здесь. Информация по API пока не переведена, но там ничего сложного. Даже с небольшими знаниями технического английского, все довольно просто, поскольку там просто описываются методы, что они принимают, отдают и что вообще делают, информация тут.

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

    Можно даже плохо владеть версткой на bootstrap, и при этом с помощью встроенных в Yii2 методов сделать всплывающие модальные диалоги, окошки, выпадающие списки, спойлеры и т.д.

    Вот небольшой пример, который можно встретить на целой куче сайтов, и даже в официальной документации Yii2:

    Пример модального окна
    use yii\bootstrap\Modal;
    
    Modal::begin([
     'header' => '<h2>Hello world</h2>',
     'toggleButton' => ['label' => 'click me'],
     'footer' => 'Низ окна',
    ]);
    
    echo 'Say hello...';
    
    Modal::end();
    


    Данный пример как раз создает модальное окно, с заголовком <h2>Hello world</h2>, кнопкой click me, которая открывает этот дилог, с телом «Say hello...» и футером «Низ окна».
    Не нужно писать всякие там 'data-target="#id-modal"' или подобное, система расставит все это сама. Такие вещи в Yii2 — называются виджетами, которые может делать вообще любой программист, и тащить любой фронтенд на свою backend — сторону. Но это на самом деле и минус, самый последний о котором я говорил выше. Почему это минус разберем чуть позже, пока об удобстве этого всего.

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

    Пример стороннего виджета
    // Multiple select without model
    echo Select2::widget([
        'name' => 'state_2',
        'value' => '',
        'data' => $data,
        'options' => ['multiple' => true, 'placeholder' => 'Select states ...']
    ]);
    


    Это пример из библиотеки, позволяющей вызывать в представлениях виджет Select2, от kartik-v, ссылка на GitHub.
    Вот такой виджет подключает все скрипты, размечает input и select и обрабатывает их библиотекой Select2.

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

    Генератор моделей, котроллеров и представлений — это отдельная вещь, но связана с предыдущей частично. В Yii2, есть некая GUI область, для выбора различных генераций. Обратите внимание, у других фреймов, если и есть генераторы, то, как правило, только консольные. Здесь есть и интерфейс и очень удобно пользоваться, называется эта прелесть gii.

    Вот как она выглядит:
    image

    На картике видно что она может. Генератор моделей и CRUD самые частопригождающиеся вещи в ней. Модели генерируются не как в laravel, в интерфейсе указывается таблица, название и расположение класса для модели, с учетом пространства имен, программа сама подтягивает все зависимости (можно отключить, если не нужны), если расставлены foreign key, и «выкатывает» модель, со всеми свойствами взятыми по колонкам таблицы и методами для связки с другими, если они есть.

    Признаюсь честно, такого генератора, я больше не видел нигде.

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

    Очень удобно использовать для создания панелей администраторов или каких-нибудь дашбордов. Быстро генерируется готовый интерфейс, который потом можно отредактировать, и пользоваться, назначив защиту роутам путем авторизации или иначе. Сам интерфейс использует множество встроенных виджетов для этого, которые тоже можно перенастраивать по своему усмотрению. Это действительно быстрая разработка систем с интерфейсами управления данных. Можно достаточно быстро сделать дельную CMS для нужд конкретного проекта. Мое мнение, что это, самый главный плюс Yii2 в сравнении с другими фреймворками.

    Теперь поговорим о минусах. О них достаточно коротко, чтобы не раздувать статью до небывалых размеров.

    Не очень гибкое формирование роутов. В контроллерах классов для Yii роуты указываются следующим образом:

    Пример создания маршрута в контроллере
    /*----*/
    
       /**
         * Your Annotation
         * @return mixed
         */
        public function actionIndex()
        {
    
            return $this->render('index', []);
        }
        
    /*----*/
    


    Любой путь в контроллере должен начинаться со слова action и с заглавной буквы указывается его адрес, например Index. Если написать из двух слов, например actionArticlesList, то путь получится следующий: /название_контроллера/articles-list. Если нам нужно как то по своему организовать формирование роутов, есть два способа:

    • Задать правила в конфиге
    • Написать свой класс для конкретной группы роутов, и указать его в конфиге.

    Подробно останавливаться на конфиге не буду, но выглядит это примерно так:

    [
    /*---*/
    'urlManager' => [
                'enablePrettyUrl' => true,
                'showScriptName' => false,
                'rules' => [
                    '<module:\w+>/<controller:\w+>/<action:(\w|-)+>' => '<module>/<controller>/<action>',
                    '<module:\w+>/<controller:\w+>/<action:(\w|-)+>/<id:\d+>' => '<module>/<controller>/<action>',
                ],
            ],
    /*---*/
    ]
    

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

    Второй пункт минусов, думаю пояснять особо не стоит. Следует обратить внимание, что Yii2 до сих пор использует bootstrap-3, и нового за последнее время в нем прибавилось достаточно мало.

    Ну и последний пункт, который я обещал пояснить — это слишком большую склеенность фронтенда с бекендом. Как и писал выше, множество виджетов и других решений, сразу делают генерацию готовых решений в представлениях (views). Это хорошо и быстро, но многие из них, выбрасывают скрипты прямо в тело страницы, в коде этих виджетов перемешан php и html, что не очень хорошо выглядит и достаточно проблематично поддерживать такой код.
    Такой метод разработки не позволяет пользоваться сборщиками типа WebPack, Gulp или другими. Точнее пользоваться можно, но придется отказаться от основного преимущества Yii2 — не пользоваться генераторами и готовыми решениями для интерфейса. Не использовать классы, которые позволяют собирать скрипты и css в assets и тому подобные сложности. А если отказаться от них, что тогда останется? Риторический вопрос!
    В современной разработке все идет к тому, чтобы как можно дальше отделить frontend от backend, и в этом плане Yii2 устаревает. Надеюсь этот минус достаточно понятен.

    Laravel


    Поскольку мы достаточно подробно познакомились с Yii2, здесь можно привести плюсы и минусы для сравнения с предыдущим фреймворком Yii2

    Плюсы


    • Имеет встроенный сборщик скриптов и scss
    • Встроенный шаблонизатор Blade
    • Очень гибкое формирование Роутов
    • Очень гибкие возможности для написания REST API
    • Быстро развивается

    Минусы


    • Большой функционал работает через фасады и IDE-системы не видят методов и свойств в некоторых классах, показывая предупреждения
    • Изучается немного сложнее Yii2
    • Нет официальной документации на русском языке
    • Нет встроенных генераторов интерфейсов

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

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

    Пример mix'a
    let mix = require('laravel-mix');
    
    mix.js('resources/assets/js/app.js', 'public/js')
       .sass('resources/assets/sass/app.scss', 'public/css');
    


    В примере стандартная конфигурация, которая у вас появляется сразу после инсталляции фреймворка. Таких миксов там можно создавать сколько угодно много, если у вас есть разделение нескольких frontend приложений.

    В примере стандартная конфигурация, которая у вас появляется сразу после инсталляции фреймворка. Таких миксов там можно создавать сколько угодно много, если у вас есть разделение нескольких frontend приложений.

    Микс сразу умеет собирать scss, однофайловые компоненты Vue, а так же в новых версиях Laravel, Vue.js идет сразу в поставке фреймворка.

    Шаблонизатор Blade, чем то сильно напоминает Twig, но синтаксис и принцип работы немного другой. Какой из них лучше не знаю, но я пока не столкнулся с такими задачами, которые можно реализовать на Twig и нельзя реализовать на Blade. Едиснтвенный минус Blade, который я пока вижу, это то, что Twig известен многим, а Blade только разработчикам Laravel.

    Очень гибкое формирование роутов. Механизм очень похож на symfony, только вместо аннотаций, используется отдельный файл и фасадный класс Route, с набором статических методов.

    Плюс по сравнению с Yii2 в том, что в контроллерах методы могут называться как угодно, и сами роуты тоже. Мы пишем их в отдельной дирректории, и указываем текущий роут, какого он типа-запроса (POST, GET и т.д.), и указываем на какой он идет контроллер и метод в контроллере. Так же можно задать имя, для вывода по нему ссылки через шаблонизатор Blade.

    Пример назначения роутов
    /*---*/
    Route::get('/dashboard/newsList', 'DashboardController@newsList')->name('dashboard/newsList'); //Запрос GET, его адрес, вторым параметром указывает на контроллер и метод
    
    Route::middleware('auth')->delete('/dashboard/newsList/news/{uuid}', 'APINewsController@DeleteNews'); //Запрос DELETE, требующий авторизации, передающий последним параметром в URL uuid, И направленный на соответствующий контроллер и метод.
    /*---*/
    


    В роутинге удобно использовать middleware, которые перед тем как отправить запрос на обработку контроллера могу проверить какие-то данные и в зависимости от них отправить контроллеру на обработку или нет. Одним из таких проверок может быть авторизация пользователя в системе. Причем сами middleware можно использовать как в контроллере, так и при объявлении маршрута в routes.

    Система получается очень гибкая. Можно на один маршрут, в зависимости от метода передачи HTTP-запроса назначить разные обработчики одного контроллера.

    Я не указал об этом в Yii2, но там тоже есть система управления такими запросами, но как и все другие роуты, настраивается или через собственный класс или через конфиг, что не всегда удобно. В Yii2 есть yii\rest\ActiveController — который позволяет быстро настройить REST FULL API, но он тоже не так гибок, как хотелось бы.

    Благодаря такой системе роутов, я бы выбрал именно Laravel для построения проекта работающего на REST API. Таким образом, в данном пункте я ответил и на следующий плюс «Очень гибкие возможности для написания REST API»

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

    Переходим к минусам.

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

    Проще привести пример. Мы объявляем класс модели работы с базой данных, которая является расширением стандартного класса Illuminate\Database\Eloquent\Model, в котором нет статических методов where, select и т.п., но на самом деле они есть и ими можно пользоваться. Вот такие чудеса. Дело в том, что такие методы образуются из так называемых фасадов, которые считывают обычные методы класса и превращают их в статические. А свойства получаются путем обращения к базе данных. Конечно удобно, что можно с одними и теми же свойствами работать и статически и динамически, но таким образом, получается что IDE не видит данные методы и показывает предупреждение о вызове несуществующих методов. Правда для этой проблемы уже есть решение — использовать IDE-helper, который решает проблему. Даю ссылку на GitHub. На GitHub довольно подробно расписано как с ним работать и устанавливать.

    Пункт «Изучается немного сложее Yii2» нельзя считать объективным, так как это лично мое мнение. Мне было достаточно сложно перестроиться после Symfony и Yii2 на эту магию с фасадами. Однако, если хорошо подумать, я посидев пару дней над гайдами и мануалами, тоже начал потихоньку писать на нем, совершенствуя свои знания и навыки.

    Мне кажется, что если бы я начал изучать сначала Laravel а потом Yii2, я бы сказал, что Yii2 было сложнее изучать, так что тут дело каждого и субъективно. В любом случае, изучать их довольно просто оба.

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

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

    Генераторы в Laravel вообще далеки от Yii2, но кое-что они всё-же могут. Есть генераторы консольных команд, которые дают готовый каркас для работы с консолью, генераторы моделей, контроллеров и другие. Но в отличии от генераторов Yii2 — они пустые. Т.е. Если мы генерируем модель, она будет пустая. Нужно самим указывать какое поле будет являться первичным ключом, к какой таблице она относится, какие имеет связки и т.д. Некоторые говорят, что это добавляет гибкости, но ведь в Yii2 вы тоже можете удалить стандартную генерацию и написать свою. Не думаю, что это тема для споров. Тут Yii2 определенно победитель.

    Заключение


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

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

    Laravel — когда у нас есть особые требования к фронтенду и чуть побольше времени на разработку интерфейсов. А так же при необходимости полного разделения frontend'a от backend'a.

    Какой фремворк изучить первым, выбирать вам, по этому поводу я написал свое мнение. Надеюсь столь подробная информация позволит вам сделать правильный выбор! Желаю всем удачи в разработке и интересных проектов!

    Ссылки


    Официальный сайт Symfony
    Официальный сайт Yii2
    Официальный сайт Laravel

    Ссылки из статьи:

    Yii Select2 от kartik-v.
    Официальный сайт Select2.
    Гайды на русском языке для Yii2 (официальная документация)
    API Yii2 (официальная документация)

    То что обещал дать в тексте статьи:

    IDE-helper для Laravel (GitHub)
    Русскоязычная документация Laravel с примерами (не официальная, но хорошая)
    Поделиться публикацией

    Похожие публикации

    Комментарии 150
      +3
      Ни в коем случае не ведитесь на «простоту» Yii! В качестве первого фреймворка ни в коем случае не рекомендую — плохому научитесь. Сделайте по простенькому проекту на Laravel / Symfony / ZF и выберите тот что понравится. Не нойте что сложно (не сложно!) — это окупится с лихвой в будущем.
        +2
        Ваше заявление звучит примерно так: «Если вы хотите использовать простой инструмент, используйте вместо него сложный».

        Вы советуете начинать изучение фреймворков с тех, что сложнее, и велика вероятность, что человек не осилит, и пойдет дальше говнокодить на коленке. Как по мне, то лучше сначала начать с простого, постепенно усложняя, чем сразу нырять в омут с головой.
          +2
          Я вкладывал немного другой смысл — «не гонитесь за ложной простотой». Луше вложить немного усилий в самообразование и получить хороший старт для дальнейшего роста.

          И да, я более чем уверен что меня мало кто послушает. Проще «говнокодить на коленке» на Yii, чем задумываться над тем, почему же в шаблоне нельзя делать «SomeModel->listAll()» и многие другие славные вещи…

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

            С этим я согласен, если бы я изначально по такому пути пошел, то сэкономил бы годы. Даже если бы я прочитал эту статью на заре становления своей карьеры, то вряд ли прислушался. Хочется же побыстрей, все и сразу.
              0
              В точку, менторство у нас не в чести, увы. Сколько хороших советов мне не дали в свое время… )))
              –1
              Ха, про выстрел в ногу точняк. Это даже с виджетами для фронта можно соеденить. Соберешь фронт себе на бек и будешь сам его потом палкой ковырять, а когда проект разрастется и потребуется разделить обязанности, будут большие сложности, вот это и есть выстрел себе в ногу, поэтому я и назвал это и минусом и плюсом
                +1
                Может я слишком категорично высказался, но в последнее время много проектов на Yii пришлось просмотреть — везде схожие ошибки. Наболело. И просматривая список вакансий постоянно вижу именно Yii. Да, просто, да быстро. Но чтобы тянуть на нем более-менее серьезный проект, на старте нужен серьезный опыт.
                  +3
                  Тоже самое и в случае Laravel происходит. Слишком много он позволяет. А новички хотят скорее начать, не понимая к чему это приведёт в будущем.

                  Да вот те же самые фасады. Мало кто понимает, что их стоит использовать лишь в качестве хелперов, например в консольке или миграциях, а для бизнес-логики только DI. А потом открываешь какой-нибудь проект и видишь методы контроллеров по 500 строк каждый, которые при этом ещё и копипастятся. Хотя бы сервисный слой для этого? Какой сервисный слой? Не… не слышал =)

                  Кажется, что это «бич» любого решения с низким порогом входа, но склонен согласиться с тем, что в случае Yii — там на порядок сложнее вывести такой проект в адекватное состояние. Хотя тут я не слишком объективен.
                    +3

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

          +3
          Yii слишком много позволяет в плане архитектуры, поэтому на нём слишком часто встречается всякой негодности. Вот что мне в нём действительно нравится, так это их queryBuilder. Доктриновский после yii'шного кажется слишком убогим.
            0
            Я бы сказал наоборот, в плане архитектуры — не очень много позволяет. Если это про расположения файлов в проекте. Тут с Ларой они одинаковы. Симфони самый развязанный в плане архитектуры. А по поводу QueryBuilder'a скажу, что чистый доктриновский да, немного сложноватый, за счет непривычности описания в аннотациях, но в Ларе например он переорганизован и ничем не хуже Yii-шного, даже немного похож, поэтому их я даже не сравнивал
              +1
              Симфони самый развязанный в плане архитектуры

              Ну… Вот тут я бы поспорил. Слишком много ограничений у симфони. Простой пример: Зарегистрировать UserInterface из секьюрити в контейнере, чтобы потом он мог резолвиться через автовайринг или парам резолвинг. Можно сделать, но это оверинжинеринг и проще сделать фектори (или дёргать токен сторадж).

              В этом плане у ларки непосредственно архитектурных ограничений ещё меньше и возможностей больше. У Symfony другое преимущество — он более развязный с зависимостями. Т.е. сами компоненты на порядок гибче, но их и так же на порядок меньше.
                –1
                Зарегистрировать UserInterface из секьюрити в контейнере, чтобы потом он мог резолвиться через автовайринг или парам резолвинг. Можно сделать, но это оверинжинеринг

                А в чем именно оверинженеринг? Простенькая фэктори + строчка в конфиге


                Symfony\Component\Security\Core\User\UserInterface:
                    factory: ['@App\UserProvider', 'get']
                  +1
                  Если честно — у меня вообще вылетел из головы этот способ. Ваша правда.

                  Ладно, другой пример. Надо для роутов добавить метаинформацию произвольного формата, при этом она должна мерджиться при наследовании (т.е. инклудах). Ну вот простой пример:
                  api.example:
                      resource: "@AppBundle/Resources/config/routing.yml"
                      prefix: /api
                      defaults:
                          _middleware:
                              - AppBundle\Middleware\QueryLogs
                              - AppBundle\Middleware\JsonResponsePrettifier
                              - AppBundle\Middleware\ExceptionsLogger
                              - AppBundle\Middleware\CrossOrigin
                              - AppBundle\Middleware\ThrowableToExceptionsTransformer
                  


                  Проблемы:
                  1) Можно указывать только строки или массивы (т.е. нельзя скинуть ссыль на сервис)
                  2) Внутри подключаемого ресурса эти параметры не мержатся.

                  Только не надо говорить, что это не Symfony-way и надо на эвенты всё вешать, а конфиги выносить в другое место. Ну вот взбрело такое в голову, присобачить миддлвари. Мы же об архитектурной гибкости говорим.
                    0
                    Для кастомщины типа последней несложно написать свой загрузчик с кастомным типом, который будет моржевать нужные дефолты
                      0
                      чтобы не получить минус я должен был привести код загрузчика? конфиг остается тем же, только добавляется свой `type` туда, а дальше строго по докам
                      symfony.com/doc/current/routing/custom_route_loader.html
                        0
                        Я хз кто минусы расставляет. По-мне, тот кто заслуживает минусов — это мои комменты. Т.к. не удосужился нормально прочитать доки, а ещё претензии к фрейму предъявляю, да ещё в формате «тостера», мол, «а подскажите, как сделать...».
                      0
                      Так это вообще не Symfony way. Вы тут свои middleware делаете что ли? В Symfony так не делают т.к в этом по сути нет необходимости, есть Lifecycle symfony.com/doc/current/components/http_kernel.html

                      Для

                      AppBundle\Middleware\JsonResponsePrettifier -> JMSSerializerBundle
                      AppBundle\Middleware\ExceptionsLogger -> Смотря что вы тут хотите, если ошибки фреймворка то symfony.com/doc/current/logging.html, если свои то делаете EventListener на событие kernel.request например, там можно получить метаинформацию из роута (да, текстовую, но вообще возможности роутинга позволяют создать свой загрузчик роутов который позволяет более гибко описать роутинг)
                      AppBundle\Middleware\CrossOrigin -> NelmioCorsBundle
                      AppBundle\Middleware\ThrowableToExceptionsTransformer -> Да это и так есть в symfony, для создания обработчика Exception можно создать контроллер и указать его в конфигурации. (https://symfony.com/doc/current/controller/error_pages.html)
                        0
                        Lifecycle асинхронный и на него нельзя полагаться. Может возникнуть ситуация, когда на один kernel.request возникнет два события response и controller. Миддлвари в этом плане более надёжное, гибкое и универсальное средство не предполагающее подводных камней в виде какой-то логики, которая внедряется где-то посередине и всё ломает, меня последовательность и количество событий.

                        P.S. Имхо, работа поверх кернел эвентов — это фатальная проблема архитектуры фреймворка, т.к. они ограничивают и возможности симфони и отказаться (задепрекейтить) от них невозможно, т.к. сам симфони не умеет как ларка — взять и поменять кусок ядра в новом мажоре, посчитав старый подход тупиковым.
                          0
                          В версии 3.4 очень много всего задеприкейтили, а в одновременно вышедшей 4.0 это же выпилили.
                  0

                  как бы расположение папок в проекте очень далеко от понятия архитектураю И что в Yii что в Ларе любые пути можно переопределить

                +3
                Большой функционал работает через фасады и IDE-системы не видят методов и свойств в некоторых классах, показывая предупреждения

                Все «фасады» лежат в конфигах, в файле app.php. Первым делом при старте нового проекта — берёте и удаляете вообще всё, что там лежит. И никаких фасадов.

                «Фасад» в терминах Laravel — это статический прокси + локатор на сервис внутри DI. Подчёркиваю, внутри DI. Каждый сервис может инжектиться (в том числе через автовайринг) по интерфейсу, такие интерфейсы в рамках Laravel называются «контрактами», так же как бины (bean) в Spring.

                Механизм очень похож на symfony, только вместо аннотаций, используется отдельный файл и фасадный класс Route, с набором статических методов.


                В классе роутов нет ни одного статического метода. Например: github.com/illuminate/routing/blob/master/Router.php#L139

                Нет документации на русском языке.

                Есть же: github.com/LaravelRUS/docs Не вся (т.е. не совсем актуальная), но этого достаточно более чем, т.к. 95% кода и описания возможностей не сильно меняется между минорными версиями.

                UPD: Не увидел ссылки в футере. Всё ок =)

                Увы, не могу оценить часть про Yii2, т.к. в основном использую другие фреймворки (в частности Symfony), но судя по части про Laravel — его вы знаете крайне поверхностно, что делает эту статью довольно субъективной, без попыток реального сравнения возможностей.

                С другой стороны — могу подтвердить, что в Yii2 действительно генераторы кода мощнее, но ничего не мешает в Laravel так же указать ссылки на шаблоны для генерации кода.
                  0
                  Спасибо за комментарий. Я не видел смысла вдаваться в дебри смысла работы фасадов, скорее это предупреждение, что придется с этим столкнуться, поскольку ни в Yii2 ни в Symfony этого нет. Но то, что вы описали в комментарии — очень хорошо. Спасибо за дополнение!
                    +2
                    поскольку ни в Yii2 ни в Symfony этого нет.


                    Сам механизм, который делает всё тоже самое и содержит точно такие же проблемы есть и в Yii и в Symfony.

                    Сервис локация (фасады и проч)
                    Laravel:
                    \DB::xxx();
                    


                    Yii:
                    Yii::$app->db->xxx();
                    


                    Symfony:
                    $container->get('doctrine')->xxx();
                    



                    Это называется сервис-локацией и порождает скрытые зависимости. В случае Laravel — это заменяется на обычный DI, в Symfony — точно так же на DI, при этом сейчас (в последних версиях) обращение к контейнеру через get — вызывает ошибку доступа. Надо явно прописывать что этот сервис публичный.

                    DI (как делать по-нормальному)
                    Laravel:
                    public function __construct(Connection $conn) 
                    {
                        $conn->xxx();
                    }
                    


                    Symfony:
                    public function __construct(EntitManagerInterface $em)
                    {
                        $em->xxx()
                    }
                    


                    Yii2:
                    А тут я фиг знает как, т.к. не шарю Yii. Покажете пример?)
                      0
                      Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию
                      $connection=Yii::app()->db;
                      

                      Но это как раз через фасады, которые в конфиге задаются. Либо расширением класса ActiveRecord, чем и являются модели. Тут просто не доктрина, поэтому сложно провести аналогию, принцип немного другой.

                      А в той же ларе или симфони, можно получить низкоуровневый объект PDO

                      Я не совсем об этом речь вел. Модели я чисто для примера взял. В Ларе например и в роутах используются методы Route::post(/***/), которые по факту не являются статичными. Я в общем о том, что такие явления есть
                        0

                        Как-то так:


                        Yii::$container->get('db');

                        vs


                        public function __construct(\yii\db\Connection $db)
                          0
                          Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию

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


                          Ну вот есть какой-то класс, например database query logger, зарегистрируем его в контейнер (можно же?) по имени "dbQueryLogger". Как сказать проекту, что получая Yii::app()->dbQueryLogger (или как-то так, поправьте если ошибаюсь) нужно создавать этот объект и прокидывать туда соединение с базой + PSR LoggerInterface.


                          UPD: О, VolCh ответил на вопрос. Спасибо. А в методы прокидывать так же можно?

                            0

                            Что-то типа


                            $controller = new class
                            {
                              public function indexAction(\yii\db\Connection $db) 
                              {
                              }
                            }
                            Yii::$container->invoke([$controller, 'indexAction']);

                            ? Не уверен, что сработает с анонимным классом, хотя не вижу причин почему нет :)

                              +1
                              Прикольно. Почитал доку — убедился что это так (кажется, надо было чуть раньше, а не мучать вопросами на хабре? =) ). Даже ребинд параметров завезли для этого invoke (второй аргумент). Ещё чуть-чуть и почти до Laravel дотянет.
                          0
                          Да, зря контроллер в Symfony сделали ContainerAware… )
                            +1
                            К счастью они уже давно осознали эту проблему и планомерно избавляются от этого в рамках BC
                            0

                            По Yii 2 пример ровно такой же :) Инъекция через рефлексию в конструктор поддерживается.

                        0
                        Также хочу дополнить, что Yii2 на самом деле не очень-то привязан к Bootstrap 3. Можно не использовать пакет 'yiisoft/yii2-bootstrap', а вместо него подключить, например, 'digitv/yii2bootstrap4', — и имеем набор классов-виджетов Bootstrap 4
                          0
                          Безспорно. Можно и свои расширения с виджетами написать и тем же функционалом и юзать например bulma вместо бутстрапа. Но речь то о том, что у него встроенно из коробки, а не установлено из вне.
                            0
                            В данном случае — просто в приложении-шаблоне (https://github.com/yiisoft/yii2-app-basic) в файле composer.json указана зависимость 'yiisoft/yii2-bootstrap'. Если не разворачивать приложение из шаблона, а организовывать структуру проекта самому (ну, или же просто убрать эту зависимость), — пакет не будет доступен. Он не прибит гвоздями, насколько я знаю.
                              0
                              Да это понятно. Так в любом решении, можно любой пакет заменить на другой или собрать по частям. Речь о работе из коробки, без лишних заморочек и для типовых задач. Когда человек выбирает фреймворк, на котором он будет учиться писать, он не собирается делать Highload проекты и пересобирать фреймворк. До этого еще дойти надо!
                                0

                                Кажется, я неточно выразился.
                                Я имел в виду то, что Bootstrap3 можно заменить заменой строчки в composer.json. Мне кажется, это — не пересборка фреймворка

                          0
                          В Yii2 есть yii\rest\ActiveController — который позволяет быстро настроить REST FULL API...

                          Вот как раз REST FULL API он и позволяет делать.
                          А вот RESTful все таки удобней разрабатывать используя функциональные возможности Laravel
                            0
                            Я это и имел ввиду, в чем смысл комментария?
                              0
                              У Вашего текста всего лишь терминология изменена.
                            0
                            В Symfony (3) из коробки 4, если не ошибаюсь, 4 способа задавать роуты, да и вообще конфиги: php, yaml, xml, annotation. И не понимаю, почему Symfony низкоуровневый фреймворк — уровень у него обычный для современных фреймворков. И не фреймворк laravel построен на базе фреймворка symfony, а фреймворки laravel и symfony построены на базе компонентов symfony, первый в меньшей степени, второй в большей.
                              –2
                              image
                              С первой страницы официального сайта симфони. Означает, что используются не компоненты, а именно фремворк. А Вот Yii использует именно компоненты.

                              А низкоуровневый — это как аналогия языков программирования. Типа PHP, JAVA, PYTHON языки высокого уровня, а C, C++ или Асемблер низкоуровневые языки. Тут дело в доступности данных низкого уровня (дампы или ячейки памяти, отдельные биты в кластерах), а не в том, как роуты задаются
                                0

                                Symfony — это набор компонентов, который называется "фреймворком". Так же как, например, Illuminate — тоже "фреймворк".


                                Сборка приложения в симфони называется symfony flex или symfony standard. У Illuminate же называется Laravel. Что тоже называют фреймворками, хотя это только сборка.

                                  0

                                  https://github.com/symfony/framework-bundle — вот фреймворк симфони
                                  https://github.com/laravel/framework — вот фреймворк ларавел

                                    +3
                                    github.com/symfony/symfony — вот фреймворк симфони.
                                    А github.com/symfony/framework-bundle — это FrameworkBundle использующийся в составе фремворка

                                    Symfony более низкоуровневый фреймворк

                                    Имхо автор не имеет реального опыта работы с симфони и краем глаза увидел что компоненты симфони используются в Laravel и т.д… Symfony фреймворк в том же смысле что и Laravel позволяющий реализовывать хотя бы тот же MVC паттерн
                                  +1

                                  Так чем у симфони уровень ниже чем у ларавеля? какие, например, абстракции не предоставляет симфони?

                                    0
                                    Ай, ну как же не понять то. Низкоуровневый — не значит хуже или что то невозможно реализовать или чего-то не предоставляет. Низкоуровневый язык программирования означает, что ты можешь работать с данными не на уровне объектов и чисел и строк, а на уровне дампов памяти, битов, положения битов в кластере и тому подобные вещи. В аналогии с фреймворками я имел ввиду, что для Симфони ты будешь больше писать ручками, для осуществления каких-то типовых задач, которые в свою очередь в Ларе и Юии имеют готовые решения.
                                      0
                                      Хлебные крошки?
                                        0

                                        Так каких "каких-то"? У каких типовых задач по разработке на PHP нет готовых решение в symfony и есть в yii/laravel?


                                        В Symfony есть абстракции над http и сессиями, роутинг, шаблонизация, кеширование, работа с формами, валидация, работа с ФС, контроль доступа, DI, i18n, l10n и переводы, конфигурация, сериализация, работа с процессами ОС, свой http-клиент и работа с DOM, бридж к ORM, бридж к свифтмейлеру, бридж к пхпюнит, бридж к монолог, бридж к твиг, средства отладки и профилирования. Что ещё нужно от фреймворка?


                                        Генераторы не в счёт, они не являются частью фреймворка как каркаса приложения, они часть экосистемы вокруг каркаса.

                                  +1
                                  Ну и замечание: многие вещи в плане разделения frontend/backend будут сделаны в Yii 2.1. Как минимум — отказ от привязки к jQuery. Разработчики прекрасно знают о подобной исторической проблеме архитектуры и пытаются ее постепенно решить по мере возможностей.
                                  Но в плане разработки сайта на коленке с простой админкой — это очень сильная сторона Yii. По сути можно сделать на нем простой блог за 30 минут и это не преувеличение.
                                    +1
                                    С этим полностью согласен!
                                    0

                                    Интересно, с каких это пор в симфони стали отсутствовать инструменты для решения небольших типовых задач?
                                    А если выбирать из 2х зол, я бы выбрал меньшую — Laravel.

                                      0
                                      Приведу пример. В Симфони есть генератор готовых интерфейсов? Встроенный удобный сборщик фронтенда как у Ларавел? Помельче: хелперы для работы с конфигами, или какими-то данными. А интерфейсы для данных — это вполне типовая задача.
                                        0
                                        В Симфони есть генератор готовых интерфейсов?

                                        https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html


                                        Встроенный удобный сборщик фронтенда как у Ларавел?

                                        https://symfony.com/doc/current/frontend.html

                                          +1
                                          Разговор про с коробки! Доставить можно все что угодно. И в Симфони правильно делают что не ставят в коробку. В последней версии вообще много чего выпилили с того, что было раньше, все можно поставить, но отдельно, и по мере надобности. Мне нравится такой подход. Но разговор шёл про «из коробки». Здесь не о чем спорить. Для многих типовых решений есть куча отдельных библиотек написанным самими SensioLab и сторонние решения.

                                          symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html

                                          Это совсем не то, что делает Yii. Этот генерирует только php файлы с классами, а у Yii это и модели и контроллеры сразу с данными и готовое сверстанное представление
                                            0

                                            https://github.com/symfony/website-skeleton/blob/4.0/composer.json


                                             "require": {
                                                    // ...
                                                    "symfony/webpack-encore-pack": "*",
                                                    // ...
                                                },
                                                "require-dev": {
                                                    // ...
                                                    "symfony/maker-bundle": "^1.0",
                                                    // ...
                                                },
                                              0
                                              Мейкер был. А вот вебпака вроде не было, до недавних пор. Может я ошибаюсь, но это все равно не то. Мейкер тут точно такой же как в Ларавел, точнее в Ларавел он заимствован из симфони скорее всего. А вебпак все равно надо настраивать, как с миксами легко не получится. Но это не в минус, это как раз больше к свободе действий.

                                              Не поймите меня не правильно. Симфони я очень уважаю. Но для типовых проектов, которые мне приходилось делать быстрее сделать на Ларе или Юии. Симфони лучше подходит для планирования хорошей архитектуры и мощных нагруженных проектов. Для толстых проектов, совмещающих в себе кучу мелких, я бы бесспорно выбрал Симфони. А если писать что-то типа Алибабы, Ебэя или Что-то еще более крупное. Лучше вообще избегать фреймворков, поскольку тут очень важно продумать свою разумную архитектуру, чего не делает один человек. Не думаю что Гугл или Яндекс пишут на каких-то фреймворках, скорее разрабатывают свои. Но это лично мое мнение
                                                0

                                                Сейчас большинство проектов делается согласно принципу “Api first”. А в нагружённом проекте вообще всегда зоопарк технологий а не фреймворк.

                                                  0

                                                  Нет. Большинство проектов делается и будет делаться с генерацией HTML. Потому что большинство — это совсем простые проекты где API не нужен.

                                                    0

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

                                                      0

                                                      Да, к сожалению, следуя моде частенько наворачивают приложение там, где на самом деле уместней была бы простая генерация HTML. Но это пройдёт. Уже ни раз было...

                                                      0
                                                      Так может там и фреймворк не нужен?
                                                        0

                                                        Смотря сколько HTML генерировать :) В некоторых случаях и PHP не нужен и лучше взять какой-нибудь Hugo.


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

                                                +1
                                                Это совсем не то, что делает Yii.
                                                Laravel тоже так не умеет, на сколько я помню, но его вы почему-то включили в обзор
                                                  0
                                                  Symfony начиная с версии 4 как раз следует парадигме «доставь все что тебе нужно». Чем-то напоминает Flask из мира python. На старте это готовый микрофреймворк, но собрать из него можно что угодно.

                                                  Было ли это хорошим решением — время покажет. Лично мне нравится, хоть и непривычно что Doctrine и Twig по умолчанию отсутствуют.
                                                0

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

                                                  0
                                                  Помельче: хелперы для работы с конфигами, или какими-то данными.

                                                  Что вы под этим имеете в виду?

                                                0

                                                Где вы видели, что в проекте используется только то, что есть в самом фреймворке?

                                                  0
                                                  Нигде не видели)
                                                    0

                                                    Тогда к чему такая привязка к инструментам из коробки?

                                                      0

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

                                                        0

                                                        Как раз все дело в реализации, как по мне.

                                                          0

                                                          Сравнивать можно и нужно не то, что из коробки (особенно если коробок много по факту, скажем различные edition типа web-edition, api-edition и т. п. или full-edition, standard-edition, micro-edition), а то, что предоставляет вендор прежде всего. Если в доках фреймворка X написано про фичу Y "перед использованием подключите Y с помощью composer req x/y", то это не повод исключать из сравнения.

                                                    0
                                                    Сразу предупрежу вопрос о том, почему не рассматриваем Symfony.
                                                    Дело в том, что Symfony более низкоуровневый фреймворк, который чаще берут для основы в крупных проектах, например таких, как написание собственного фреймворка для разработки.
                                                    Ерунда какая-то написана. Мы используем Symfony и в крупных и в мелких проектах и никаких костылей вроде собственных фреймворков не пишем.
                                                    Вы вероятно имели в виду бандлы, а не сам фреймворк. Из отдельных бандлов/либ да, можно набросать свой собственный фреймворк (в этом собственно прелесть модульной архитектуры) если уж очень колется, но только зачем? :)
                                                    Его в принципе нельзя сравнивать с Laravel и Yii2, так как они используют его компоненты в своих реализациях.
                                                    Ну вот вы сами ответили на свой вопрос.
                                                      0

                                                      Бандлы как раз очень симфони-специфичная вещь, речь именно о компонентах.

                                                      +1
                                                      В 2015г. я бы еще обратил внимание на Yii.
                                                      На данный момент, не вижу в нем хотя бы одного плюса.
                                                      Правда я фанат Symfony DDD/CQRS/Bus/EQ… Потому мое мнение совершенно бесполезно.

                                                      На тему крупных проектов, видимо автор застрял в 2015-2016гг. и не знает о существовании Symfony 4.
                                                      Соответственно, считать данный пост серьезным, совершенно нельзя.
                                                        0
                                                        Я бы отмотал еще лет 7 ) Если и сравнивать Yii то с Symfony 1.x, ZF1.x (год 2007-2008й). Кстати у Symfony тогда был админ-генератор из коробки))
                                                          0
                                                          Да, был. Но я в то время на Zend писал и осваивал Yii, который был в тренде.
                                                          Но сейчас, выбор мой SF, но если смотреть на другие, то конечно laravel.
                                                          Причина проста — организация кода, архитектурный принцип и конечно ioc.

                                                          В добавок, удобно реализовать DDD. Хотя тоже надо будет поковыряться и написать обработчик для входящих данных, что бы использовать геттеры
                                                            0
                                                            Я тогда выбрал Symfony (из-за схожести с RoR, который тогда тоже был в тренде, но не только — делал несколько небольших проектов то на одном, то на другом фреймворке, сравнивал грабли). И не пожалел, вторая версия, хоть поначалу и казалась сложной, повернула мозги в правильном направлении.
                                                              +1
                                                              Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного, так что ниша Yii/Laravel довольно большая.

                                                              IoC есть и в Yii и в Laravel. В Yii в основном практикуется ServiceLocator. например вызов Yii::$app->get(); или Instance::ensure() в init() или конструкуторе хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка, а это не так уж нужно если не пишешь библиотеку.
                                                                0
                                                                Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного

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

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

                                                                  +1
                                                                  По такой логике надо во все проекты DDD закладывать «на вырост», я не могу с этим согласиться, «на вырост» часто оказывается вредным.
                                                                    0

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

                                                                  0
                                                                  DDD — любой проект, где существует серьезная бизнес логика. Проекты, где важен бизнес а не ЧСВ разработчика.
                                                                  Сначала реализуется бизнес-логика, которая не зависит от приложения, затем делается остальное.
                                                                  Вот главная цель DDD.
                                                                  Конечно, применять в мелких сайтах и петпроектах не имеет смысла.
                                                                  Но я не говорю о таких проектах, их можно реализовать хоть на html и пару микросервисов. Я даже не считаю подобные проекты работой.

                                                                  Т.е. вывод прост, вы не представляете что такое DDD и для чего.
                                                                  Или просто не работали над серьезными бизнес-проектами с миллионными инвестициями.
                                                                    +1
                                                                    Главная цель DDD это устранение сложностей с пониманием предметной области и создание реализации, максимально близкой к модели предметной области, чтобы ее удобно было понимать и поддерживать.

                                                                    По вашему серьезные проекты невозможны без DDD?) Большинство проектов на Yii не сделаны по DDD, их вы тоже не считаете работой?) Жгите дальше.
                                                                      +1
                                                                      Нет, почему же.
                                                                      Можно написать хоть обычными функциями на PHP4 (делал банковскую CRM в 2007г.).
                                                                      Вы мне напомнили людей с развлекательных сайтов, которые читают первую строчку, затем среднюю и последнюю.

                                                                      Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
                                                                      Я не писал, что невозможны серьезные проекты без DDD.

                                                                      Вы как западные политики, придумываете то что вам удобно.

                                                                      Почему для слепых котят, надо все пояснять и выделять жирным текстом?

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

                                                                        0
                                                                        Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
                                                                        Я не писал, что невозможны серьезные проекты без DDD.

                                                                        Вы как западные политики, придумываете то что вам удобно.

                                                                        Почему для слепых котят, надо все пояснять и выделять жирным текстом?


                                                                        Извините, я неправильно понял ваш комментарий.
                                                                        0
                                                                        Не вижу что кто-то писал, будто без ДДД невозможно реализовать крупное программное решение.
                                                                        Доменый слой существует для реализации логики в отрыве от данных и приложения.
                                                                        Вы пишите логику, основываясь на требованиях бизнеса. Домен, дает прекрасную возможность, подстраиваться под веяния бизнеса.
                                                                          0
                                                                          А без DDD вы логику на основе чего пишете?
                                                                            0
                                                                            Как обычно, бестпрактик.
                                                                            Но это к сожалению не дает возможности, быстро перестроить логику, если что то кардинально изменится.
                                                                            Соответственно это время и деньги бизнеса.

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

                                                                            То тут имелось ввиду, что в ДДД пишут, не именно вы =)
                                                                            Пишу статью, образ речи сохраняется и в комментариях =)
                                                                              +1
                                                                              Я хотел сказать, что любые приложения всегда пишутся по требованиям бизнеса, DDD здесь не монополист. Да, по сравнению с обычными приложениями, в DDD код более абстрактный и иногда легче по нему понять сложную бизнес-схему. Но это актуально только для реально сложных проектов, там где логика простая, DDD привносит больше сложности, чем снимает. Основная цель DDD борьба со сложностью, но для этого нужно сначала убедиться в том, что эта сложность действительно есть и она будет доставлять проблемы.
                                                                              0

                                                                              Без DDD вы, грубо говоря, не выделяете бизнес-логику в отдельный слой, независимый ни от чего кроме бизнес-требований. Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и "моделями" (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в "моделях", а не в контроллерах.


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

                                                                                +1
                                                                                Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и «моделями» (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в «моделях», а не в контроллерах.



                                                                                Ну в таком случае можно сказать, что в DDD-проекте она размазана между сущностями и сервисами, и хорошо, если большая часть в сущностях, а не сервисах, чтоб не получились анемичные сущности.

                                                                                  0

                                                                                  Существенное отличие между нашими фразами — в вашей нет слов "унаследованного от базового класса". В DDD бизнес-логика размазана по слою бизнес-логики и ни от чего не зависит. В типичном Yii/Laravel приложении бизнес-логика размазана между моделью, совмещающей по определению бизнес- и инфраструктурную логики, и контроллерами, реализующими по определению часть UI-логики. И, главное, и там, и там она зависит от классов, предоставляемых фреймворком. Захотите поменять фреймворк (ну или проапгрейдить на мажорную версию) — придётся разбираться где бизнес-логика, а где UI или инфраструктурная.


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

                                                                                    +1
                                                                                    Я думаю, что это абсолютно нормально, когда для решения какой-то задачи берется популярный, поддерживаемый фреймворк и код зависит от него. В этом ничего плохого я не вижу и считаю это нормальным. Да, при смене мажорной версии придется приложить усилия, заменить какие-то вызовы, базовые классы, отрефакторить проект. C DDD эти усилия прикладываются наперед, но несколько в другом виде — абстракции. домена. Но и это спасет от рефакторинга лишь часть проекта. При замене фреймворка/мажорной версии все равно придется много переделывать. Инфраструктурный слой все равно придется переписать, а этот слой чаще получается даже намного толще доменного.
                                                                                    Я предпочитаю не закладывать наперед возможность смены фреймворка/мажорной версии, так как это порождает много абстракций, которые замедляют и усложняют разработку (надо больше думать для выделения хороших абстракций), чтобы потом облегчить гипотетическую смену фреймворка, которая может и не понадобиться вовсе. Некоторые проекты на Yii1 спокойно продолжают работать.

                                                                                    Фреймворконезависимость обходится дорого, она добавляет забот. Помимо реализации требований, приходится решать задачи по абстракции.
                                                                                    Да, иногда, она оказывается полезной, но я нахожу такие ситуации довольно редкими.
                                                                          +1
                                                                          Правда я фанат Symfony DDD/CQRS/Bus/EQ…


                                                                          Вот, сразу виден фанатизм. Он ослепляет.

                                                                          Я пробовал применять DDD в проекте. Что получилось — то же самое что и было без DDD, только работы больше по абстракции домена. Кода стало реально больше. Оверхед был налицо, поэтому для себя я сделал вывод, что DDD нужно применять только тогда, когда есть проблемы коммуникации(!), домен реально сложный и нетиповой.

                                                                          О недостатках DDD в википедии

                                                                            +1
                                                                            Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.
                                                                            Доработали доктрину, реализовали сериалайзер и маппинг бандлы.

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

                                                                            Я вам открою секрет, на текущий момент, я больше фанат Golang и laravel. Но это только в отрыве от бизнеса.
                                                                              +1
                                                                              Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.


                                                                              4 месяца без кода, ну это большой риск. И что прототипов даже не писали?

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


                                                                              Вот именно, что можно, но нужно ли? Вам это дало какой-то профит, если не секрет, какой? Повторно использовали домен в другом проекте? Так он же уникальный, разве нет? В чем именно получилась реальная выгода, если не секрет?
                                                                                0
                                                                                Нет. Блок схемы в основном. Продумывали алгоритмы.
                                                                                У нас было время, т.к. проект уже работал (кстати на YIi частично), но он не отвечал двум основным требованиям. Это нагрузка (на 50 обращениях уже не вытягивал именно PHP, не БД. До нас делали по доке проект), вторая проблема, это изменения поведения внешних клиентов которым поставляются данные (booking.com, trivago и др. букинг товарищи).

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

                                                                                Профит — я уже сказал по сути. Быстрая смена работы под определенные бизнес-решения. Домен используется и в др. проекта, как вы верно заметили. Домен не совсем уникальный, он имеет модели, репозитории, логику для определенных вещей букинг бизнеса, что в 90% случаев одинаково.
                                                                                Для использования домена в другом проекте (условие только SF), надо подменить для своих нужд хендлеры, если это требуется и/или объекты ответа заменить.
                                                                                Слой приложения пишется свой, у каждого свои потребности.
                                                                                  0
                                                                                  Признаю, в описанном случае DDD полезен.
                                                                              +1

                                                                              В каком плане "то же самое"? Если работы по абстракции больше, то значит не то же самое, а абстракция сильнее, нет?

                                                                                +1
                                                                                «То же самое» — имеется ввиду реальная работа, которую выполняет код. Да, абстракция стала сильнее, но внедрять новые функциональные возможности, как ни странно, стало сложнее. Приходится думать, как новое ляжет на существующие абстракции, а если не ложится, приходится их модифицировать вместе со всем соответсвующим инфраструктурным кодом. Да и просто больше файлов надо просмотреть и отредактировать.
                                                                                Сначала меня DDD увлек, я думал, он мне поможет упростить работу, а на практике оказалось нет. Проект не настолько сложный и большой, команда 3 человека в одном офисе.
                                                                        +1
                                                                        Даа. Админ-генератор был сказка. Мы вот в sf4 юзаем EasyAdmin и плюёмся :(
                                                                        Я так понимаю кроме жирной Сонаты и EasyAdmin больше вариантов нет?
                                                                          0
                                                                          Если и есть, то хуже по качеству.
                                                                          Хотя я особо не искал.
                                                                          SF в 99% используется для реализации API, остальное swagger + экспорт в postman.
                                                                            +1
                                                                            Нормальных я не видел. EasyAdmin использую для чего-то совсем простого, в остальных случаях пишу свои решения. Sonata, при всем моем уважении к труду сообщества, слишком медленная и переусложненная. Я отказался от ее использования после долгих лет мучений… )
                                                                        +1
                                                                        Работа через фасады, большинства обширных классов Laravel. Такое сложное предложение, я поясню! Дело в том, что во многих классах фреймворка используется динамическое создание свойств и методов, в зависимости от каких-то условий.
                                                                        Проще привести пример. Мы объявляем класс модели работы с базой данных, которая является расширением стандартного класса Illuminate\Database\Eloquent\Model, в котором нет статических методов where, select и т.п., но на самом деле они есть и ими можно пользоваться. Вот такие чудеса. Дело в том, что такие методы образуются из так называемых фасадов, которые считывают обычные методы класса и превращают их в статические. А свойства получаются путем обращения к базе данных.

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


                                                                        Плюс Yii2 — в том что он очень лоялен к новичкам, можно генерацию из интерфейсов делать, без консоли, можно минимум js знать, тонны виджетов на каждый чих; и он же — большой минус так как тормозит развитие и изучение сопутствующего стека, оставляя зацикленными на jquery-bootstrap
                                                                        И очень не хватает для Yii2 аналога laracast

                                                                          +1
                                                                          Да, Yii/Laravel + VueJs на мой взгляд сейчас очень актуальный и востребованный стек.
                                                                          Сам работаю с Yii, очень удобно.
                                                                          Про механизмы доступа к данным что-то ничего не написали.
                                                                            +1
                                                                            Большой функционал работает через фасады и IDE-системы не видят методов и свойств в некоторых классах, показывая предупреждения
                                                                            Вас никто не заставляет использовать фасады. В Laravel есть замечательный DI с автовайрингом и это предпочтительный способ связывания.

                                                                            Изучается немного сложнее Yii2
                                                                            С моей точнки зрения все как раз наоборот, из-за огромного количества обучающих материалов по Laravel, рассчитанных на новичков. Есть даже интерактивные курсы, где в процессе обучения надо писать код.

                                                                            А по поводу QueryBuilder'a скажу, что чистый доктриновский да, немного сложноватый, за счет непривычности описания в аннотациях
                                                                            Описывайте в yaml, так удобнее.
                                                                              0
                                                                              И все же, не вижу проблем использование Symfony — он вполне прост из коробки, легко можно построить обычное приложение без особых усилий… думаю что страшилок про Symfony надо меньше читать и тогда все будет окей…
                                                                                0
                                                                                Скорее впечатления от первых релизов второй ветки. Аутентификации с авторизациями чего стоили, да и в 4, наверное, самая сложная тема для начинающих.
                                                                                +1
                                                                                С лета 2013-го до лета 2017-го моей основной задачей была поддержка и развитие проекта на symfony 1.4. Он был популярным и поддерживаемым на время старта проекта. И процентов на 90 уверен, что он работает до сих пор, хотя и ведутся работы по уходу с него. Что я могу сказать: была бы там логика отделена от фреймворка (считая doctrine1 частью symfony 1) — не было бы острой нужды в уходе с него. Минимум годовую зарплату я получил за борьбу с сильной связанностью бизнес-логики и фреймворка. Там и других косяков в архитектуре хватало, и сам я немало костылей написал под убеждением «ещё пара месяцев и так или иначе развитие остановится» буквально с первого дня работы, но основная проблема была именно в отсутствии изоляции от фреймворка и orm. По самым моим пессимистичным оценкам, пару человеко-месяцев выделенных летом 2013-года на изоляцию, окупились бы только за счёт моих задач к лету 2017-го многократно.
                                                                                  0
                                                                                  А можете описать пару проблем именно из-за связанности?
                                                                                    0

                                                                                    Навскидку, по памяти:


                                                                                    • повсеместное, буквально в каждом типе функциональных модулей, использование синглтона sfContext — имплементация Registry. Например, поступает задача в некоторых случаях модифицировать поведение реакции на http-запрос. Добавляешь get-параметр в урл, проверяешь егов контроллее, модифицируешь поведение, поведение непредсказуемое, копаешься, копаешься, а потом оказывается что это параметр используется уже где-то в модели через sfContext::getInstance()->getRequest()->get('hold')
                                                                                    • "магическая" передача динамических свойств класса контроллера в шаблоны
                                                                                    • активное использование методов типа save() в "безобидных" сеттерах или методах типа calcBalance() инстансов ActiveRecord, а то и в геттерах.
                                                                                      0
                                                                                      Да, ситуация у вас тяжелая была. Конечно, обращение к HTTP Request в модели это перебор. И я тоже против повсеместного обращения к реестру. Но вот в конструкторе, при инициализации объекта, на мой взгляд, допустимо обращаться к реестру за зависимостями. Если там будет обращение к недоступной зависимости, это быстро обнаружится, так же как и для классического конструктора. Также API класса для использования в клиентском коде становится попроще — не надо всюду все зависимости для создания экземпляров прокидывать.

                                                                                      Я раньше тоже был только за классическое внедрение через конструктор/методы, но сервис-локатор в конструкторах упрощает код и экономит время. К тому же зависимость можно прокинуть туда, куда ее через конструктор иногда не прокинешь (какая-нибудь библиотека требует, чтобы он был без параметров).

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

                                                                                      А почему вызовы save() в методах-мутаторах (изменяющих состояние) AR считаете неправильным? И причем тут сильная связанность? Я как раз наоборот, ратую за это. Тем более в Yii, если ничего не поменялось, то к базе запросов не будет.
                                                                                        0

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


                                                                                        Неявное сохранение с одной стороны, если метод не назван как-то типа calcBalanceAnsSave() — когда просто calcBalance или getBalance, то как-то ожидаешь, что максимум чтение с базы может быть, но никак не запись, причём может быть каскадная. Множественные сохранения с другой, когда мутаций несколько. Ну а главное, именно сильная связанность — бизнес-логика получается сильно связанной с ActiveRecord. Ладно бы просто в конце сеттера вызывался save, так где-то в середине, а если в конец перенести, то или не работает вообще, или сохраняет лишнее.

                                                                                          +1
                                                                                          Похоже тот, кто описываемый проект делал, вообще о порядке и поддержке не думал, просто скорее бы решить задачу. Конечно, в геттерах не надо что-то менять/сохранять.
                                                                                            0

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

                                                                                  +1
                                                                                  а еще в ларе ну очень токсичное русскоязычное коммьюнити. не один раз уже сталкивался
                                                                                    0
                                                                                    А в чем это выражается? Дают вредные советы?
                                                                                      0
                                                                                      Наоборот. Отправляют читать доку, отвечая на вопросы по основам.
                                                                                        0
                                                                                        Раз вы начали за RSalo отвечать.
                                                                                        И в чем же тогда заключается смысл фразы «токсичное русскоязычное коммьюнити»?
                                                                                          0
                                                                                          С моей стороны это была лишь ирония, т.к. есть довольно много участников, и я не исключение, которые на вопросы, вида «Почему у меня ошибка: can not call method on null» — вместо ответа на вопрос отправляют в документацию и отвечают фразами «не стоит браться за фреймворк, пока не изучил язык». Я не преувеличиваю — это действительно так, например: toster.ru/q/502732 А люди после этого начинают обижаться. А как ответить, мол, «друг, просто переведи сообщение об ошибке и всё станет понятно» — непонятно, т.к. это уже не первый и даже не второй вопросы подобного рода от некоторых начинающих. Потом такие новички обижаются.

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

                                                                                          Далее этот вопрос из под фейкового аккаунта был перемещён на стековерфлоу. При этом, для чистоты эксперимента — он был задан вообще в англоязычном сегменте (существует мнение, что на отечественных IT формуах/ресурсах — люди более «токсичные», а на зарубежных всё ок). В результате сам вопрос набрал "-2" за 2 или 3 часа, но, к слову сказать, один ответ там всё же был дан.

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

                                                                                          Я достаточно подробно расписал ответ?
                                                                                            0
                                                                                            Я достаточно подробно расписал ответ?

                                                                                            Да. Спасибо.
                                                                                              0
                                                                                              ну раз уже успели за меня ответить, пока меня не было, то просто открываешь любой русскоязычный чат по ларке и смотришь на постоянные срачеги и насмешки друг над другом
                                                                                                0
                                                                                                Можно ещё спросить «А почему Doctrine не из коробки и вообще официальной поддержки нет».
                                                                                                  0
                                                                                                  или спросить «почему такая плохая документация и где найти в их апишке нужные классы». я на стаковерфлоу один раз был задал такой вопрос, сразу же 3 минуса получил и мгновенное закрытие вопроса без ответа с комментами о моей никчемности…
                                                                                    +1
                                                                                    А я вижу главный и неоспоримый плюс Yii именно в виджетах. Такой удобной кодогенерации (разметки) я не видел ни в одном фреймворке ни на одном языке. Честно скажу — я не пользовался ларавелем, но немного читал его доки — и у него насколько я понял нет ничего подобного. Взять к примеру хелперы из ASP.NET (я вообще больше сишарпер): они генерируют лишь один тег который и обозначен в названии, например Html.TextBox — inpu а Html.Label — label. В то время как ActiveForm->field() в yii генерирует сразу инпут, вместе с меткой, валидцией и блоком для вывода ошибок. Это офигительно удобно! И хотя хелперы можно создать свои генерирующие что угодно — куда удобнее когда уже все сделано за тебя! Не говоря уже о том что в Yii встречаются виджеты легко генерирующие такую сложную (для бэкэндера) разметку которую не сверстаешь вот так сходу. Например вот этот грид (хоть и не из коробки, но установить же не проблема) я использовал в одном проекте. Нужна была такая вот многофункциональная таблица и все решилось с помощью этого чудо-виджета!
                                                                                      0
                                                                                      Если Вам виджеты нравится, Вам надо VueJs попробовать вместе с его однофайловыми .vue компонентами. Хороших результатов и высокой реюзабельности можно добиться.
                                                                                        0
                                                                                        Хорошая очень штука Vuetify. Очень много компонентов, удобно делать полноценное веб-приложение. Есть проблемы со встроенной версткой правда, кастомизировать сложно, но если к дизайну приложения придирок особых нет, то быстро и удобно. На Ларе, кстати, собирается на раз два mix'ом
                                                                                          0
                                                                                          может я не совсем правильно пользовался вуе, но блин — у меня как не крутил получался инвалид какой-то, а не удобные компоненты. чтобы построить на вуе тот же грид, нужно в любом случае подгружать в дом сырые данные, а затем уже их формировать в грид. проще уже отрендерить на серверной части, чем мудрить еще и на клиентской части. если уже делать на вуе нормальные компоненты, то уже делать на полноценном ресте, иначе получится такой же инвалид как и у меня
                                                                                            0
                                                                                            Компоненты решают эту проблему. Некоторые компоненты работают так, что можно с сервера получить, например json, собрать в объект, и объект отдать компоненту, он сам отрендерид гриды. В том же Vuetify, о котором я говорил выше, есть data-tables — компонент, который это делает. А компоненты реально удобные, сравнимы с реактовскими
                                                                                      0
                                                                                      У вас все таки получилось поднять холивар. Злые симфонисты не дадут спокойно пройти мимо них)
                                                                                        0
                                                                                        )) На самом деле очень интересно профессиональное сравнение Laravel 5.6 и Symfony 3.4/4.0 на долгоиграющих активно развивающихся проектах со сложной бизнес-логикой, учитывая, скажем так, заметно пересекающиеся кодовые базы. Как-то на небольших проектах с Laravel, сделанных по туториалам и ларакастам не очень понятны его преимущества, почему его кто-то выбирает со всей его магией и глобальными состояниями. Может как и в туториалах Symfony демонстрируется как можно быстро решить конкретную задачу, не заботясь о том, как дальше решение поддерживать. Классический пример: использование Symfony Forms в тесной связке с Doctrine Entity — bad practice с точки зрения чистой архитектуры, формы и сущности ничего общего не имеют, даже если их поля мапятся друг на друга 1:1 по случайному стечению обстоятельств.

                                                                                          0
                                                                                          Marco Pivetta в одном из своих докладов озвучивал тезис о том, что формы, примененные не к ДТО нарушают валидность объекта

                                                                                          В частности вот слайды (возможно надо поскроллить анимацию)
                                                                                          ocramius.github.io/doctrine-best-practices/#/51
                                                                                          ocramius.github.io/doctrine-best-practices/#/56

                                                                                          С другой стороны Symfony Forms не оперируют чистыми полями сущности, она работает через публичные методы, а это значит, что имея корректную DDD сущность без сеттеров (а с бизнес-логичными методами) вы не сможете привести ее в невалидное состояние формой и проблема исчезает. Но там становится сильно сложней конфигурация самой формы в таком случае, надо навешивать на нее дата мапперы, события и прочие радости жизни

                                                                                          Вот пример, как работать с VO через формы
                                                                                          webmozart.io/blog/2015/09/09/value-objects-in-symfony-forms
                                                                                            0
                                                                                            Так и я про это. А если открыть мануал симфони к формам, то там форма прямо к сущности с сеттерами биндится. Ну и по опыту многие так и делают в проектах.
                                                                                              0
                                                                                              Так это не проблема формы, это проблема моделей у которых есть сеттеры. Если у модели есть сеттеры — ей по определению (задумке, факту, хз) можно вертеть как угодно, что и используется в формах по умолчанию, т.к. это самый распространенный (к сожалению) кейс.
                                                                                              Если убрать у сущности сеттеры, то выглядеть уже будет корректно, в этом случае форма сама будет выступать как DTO + трансформер, который правильным образом переложит данные (вызвав нужные методы в нужном порядке) в модель
                                                                                                0
                                                                                                Это проблема мануала к форме :) Сделаешь модель нормальную, уйдешь в отпуск, придешь а там уже сеттеры. Спршиваешь«зачем?!», ответ «а так формы не работают, по мануалу Симфони сеттеры должны быть»
                                                                                                  0
                                                                                                  Да, забавно. Нашел это место, там действительно написано, что

                                                                                                  Unless a property is public, it must have a «getter» and «setter» method so that the Form component can get and put data onto the property.


                                                                                                  Хотя в действительности это не так обязательно, можно поменять дата маппер. Тянет на issue и PR
                                                                                                    0
                                                                                                    Оказывается, довольно горячая тема

                                                                                                    github.com/symfony/symfony-docs/issues/8893
                                                                                                      0
                                                                                                      Угу. Не раз уже поднималась в разных местах в разных вариациях.
                                                                                          0
                                                                                          По статье чувствуется поверхостное знание и Yii2 и Laravel.
                                                                                          сам я начинал с Laravel но ушел на Yii2.

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

                                                                                          Прокомментирую эти плюсы ларавел

                                                                                          > Имеет встроенный сборщик скриптов и scss
                                                                                          в Yii тоже есть встроенный сборщик. Но по мне в ларе реально удобнее.

                                                                                          > Встроенный шаблонизатор Blade
                                                                                          Он конечно прост, и в какой-то степени ограничивает говнокод. Но PHP сам по себе шаблонизатор. Я лично против дополнительных надстроек.

                                                                                          > Очень гибкое формирование Роутов
                                                                                          За все время мне еще не разу не попадалась задача на yii где не хватало бы гибкости формирования роутов.

                                                                                          > Очень гибкие возможности для написания REST API
                                                                                          аналогично предыдущему пункту

                                                                                          > Быстро развивается
                                                                                          не быстро развивается а потостоянно изменяется. Каждая новая версия слабосовместима с предыдущей. Обновления вызывают опасения. Поэтому с ларавела и соскочил.

                                                                                          в Yii всё стабильно. Критичных обновлений за последние года полтора не было. Обратная совместимость почти всегда есть. Только вот сейчас готовится критичное обновление Yii2.1 и то делают всё, что бы переход был гладким. А то вместо работы над проектом получается постоянное латание дыр за обновлениями.

                                                                                          В общем я на yii из-за стабильности перешел. Но ларевел мне по красоте кода нравится :-)
                                                                                            0
                                                                                            не быстро развивается а потостоянно изменяется. Каждая новая версия слабосовместима с предыдущей. Обновления вызывают опасения. Поэтому с ларавела и соскочил.


                                                                                            Это было только два раза за всю историю, переход с 3.х на 4.х и с 4.х на 5.х. Можно было догадаться, почему эти версии мажорные.
                                                                                              0

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

                                                                                                0
                                                                                                Да это же мелочи, причём описанные в доке (ну кроме миграций). Обновление с Symfony 3.0 до 3.4 больше времени требует, нежели ап с 5.1 до 5.5. Ну это на моей практике было так, на других проектах может быть иначе.
                                                                                                  0
                                                                                                  Что сознательно поломали с 3.0 по 3.4? Нет, были, конечно, ошибки, приводящие к поломкам BC, но это ошибки, которые фиксились. Всё наследство 3.0, 3.1, 3.2 или 3.3, от которого решили отказаться в 4.0, в 3.4 просто deprecated должно быть — это официальная подход к развитию. 3.4 от 4.0 отличается выпиливанием этого deprecated. Ап с 3.1 на 3.4 на довольно большом проекте безболезненно прошёл, после выпиливания deprecated в логах, на 4.0 тоже.
                                                                                                    0
                                                                                                    О, я забыл упомянуть, что у меня соната прикручена к симфоне.
                                                                                            0
                                                                                            Встроенный сборщик основан на WebPack

                                                                                            Очень жирный минус. Всюду таскать этого тормозного монстра… ну нафиг.
                                                                                              0
                                                                                              Привет dastanaron_dev, а есть смысл переписывать сайт на laravel, если он на yii написан? Планируем к сайту добавить личный кабинет с возможностью оплаты, говорят yii сложнее масштабировать.
                                                                                                0
                                                                                                Привет elenk_r, я думаю, что я не в праве давать в данном случае какие-либо советы, по той причине, что я не знаю ни ваш действующий ресурс, ни доработок, которые требуются сделать. Yii2 можно мастабировать, но есть определенные нюансы связывающие руки в некотором смысле, но они есть и у других фреймов. Тут надо рассматривать позадачно и по трудозатратам. Если текущий проект не сложно переложить на Laravel и он решает другие проблемы, то смысл конечно есть. Если же планируется масштабирование еще в будущем, помимо ЛК и оплат, я бы посоветовал смотреть в сторону микросервисной архитектуры, где вообще каждый сервис может работать на своем фреймворке, но это тоже несет существенные минусы, зато хорошо подходит в качестве временных переходных решений, позволяет параллельно переписывать старые сервисы на новый движок. А если текущий проект не очень большой и нужно только добавить личный кабинет с небольшим количеством настроек и оплат, тут и Yii2 с легкостью справится с этой задачей. Если в ближайшем будущем не требуется серьезных расширений, я бы оставил старый движок, так как и команде с ним привычней работать и сделать будет быстрее чем переписывать с нуля. Однако нужно еще понимать, насколько «загажен» в коде ваш текущий проект. Если там он так сделан, что масштабирование настолько сложное, что почти невозможное, то пора писать новый проект, на чем то новом.

                                                                                                Ну и еще. Если планируется серьезное масштабное расширение с кучей фич и переход на микросервисную, я бы предложил смотреть в сторону минималистичных фреймворков, типа Silex (сейчас устарел) или Symfony 4, где все лишнее из коробочной сборки выпилино, даже doctrine. Все можно установить, но уже по раздельности. Для крупных растущих проектов самое оно, есть контроллеры и все, модели и остальную архитектуру организуй как хочешь!
                                                                                                  0
                                                                                                  В целом, laravel и yii достаточно схожи идеологически, как по мне, и в общем случае переписывание смысла мало имеет. Хотя, конечно, могут быть ситуации, когда что-то конкретное в одном фреймворке сильно мешает проекту, а во втором фреймворке хотя бы мешать не будет.

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

                                                                                                Самое читаемое