YII 2.0 VS. LARAVEL

Чем Yii 2 лучше LaravelПару лет назад, я работал в одно команде php-разработчиков и перед нами предстояла цель определиться, какой php-фреймворк выбрать, чтобы можно было целиком на него положиться и продуктивно работать в дальнейшем. Мы провели большое количество исследований и в финал вышла сладкая парочка Symfony2 и Yii 1.1.14.

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

Однако, я не перестал следить за развитием других php-фреймворков. В то время, когда мы делали выбор, Laravel был совсем молодым и мы не рассматривали его всерьез. Теперь же, Laravel повзрослел и, с выходом версии 4.1,  стал очень даже привлекательным.

Laravel вырос в один из самых популярных php-фреймворков. В том числе, благодаря тому, что его автор Taylor Otwell создал интуитивно понятный синтаксис, что значительно облегчает процесс освоения, особенно для новичков.

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

Несмотря на то, что Symfony 2 имеет прекрасно написанную и подробную документацию и стройную «симфоническую» архитектуру, он имеет очень высокий порог вхождения. Я не смог найти в сети вменяемых статей или примеров о том, как создать работающую модель пользователя. Это и оттолкнуло меня от Symfony 2 в сторону Laravel. Последний в этом плане предпочтительнее: больше книг, статей и сайт Laracasts.com, который поможет с быстрым стартом.

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

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

Теперь поговорим о Yii. Я хочу сказать, что в сравнении с Symfony 2 и Laravel 4.1, Yii 1.1.14 может показаться уродцем. Очень мощный и во многих случаях гораздо проще, но не всегда логичен и легко понятен. Да, его разработчики постарались и теперь существует достаточно активное сообщество, как англоязычное, так и русскоязычное. Документация, хоть и переведена на несколько языков, содержит недостаточно примеров с исходным кодом. Laravel, на первый взгляд, на много лучше в этом плане.

Yii другой, более осмысленный, что ли. Symfony 2 и Laravel 4.1 используют миграции для создания таблиц в базе данных, что выглядит как еще один уровень абстракции. Представьте себе, что пятеро программистов будут совместно решать какую таблицу и с какими полями создавать. Это достаточно популярный подход к разработке, но не самый удачный, по моему мнению.

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

Даже в случае, когда один разработчик занимается созданием проекта, лучше заняться базой данных используя, например, MySql Workbench, чем использовать миграции. Миграции не всегда правильно обрабатывают основные ключи, что может обернуться проблемами в будущем.

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

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

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

К чести разработчиков Yii, они, во главе с создателем Qiang Xue, прислушались к сообществу и Yii 2.0 стал более понятным, логичным и полным новых возможностей, наверное, лучшим php-фреймворком, что я видел. Только представьте себе, вы получаете «из коробки» frontendbackend, работающую модель пользователя с авторизацией и работающим механизмом восстановления забытого пароля. Представьте фреймворк, который интегрирован с Bootstrap 3. Хотя, не нужно представлять — просто установите фреймворк и создайте приложение advanced. Вы будете поражены, на сколько это просто и функционально. И да, Yii2 использует composer для управления зависимостями и для установки, кстати тоже!

Мне сложно описать всю изящность архитектуры, это нужно видеть своими глазами. На момент написания данной статьи, Yii уже в версии 2.0.1, Документация дописывается и переводится на разные языки, в том числе и русский.

7 thoughts on “YII 2.0 VS. LARAVEL

  1. Alt

    Работа с созданием таблиц в Laravel ужасная. Миграции не всегда удобно использовать, хотелось бы видеть генератор таблиц из командной строки как в Sf2.

  2. Константин

    Непонятно, чем плохи миграции? Файлы миграций называются по датам/номерам тасков, выполняются последовательно..

  3. Игорь

    Мой подход:
    Первоначальное проектирование производится через ER-модели (Mysql Workbech, например) и это вполне подходит, до тех пор пока проект не стартовал, после этого ER-модели поддерживаются, но все изменения в структуру БД вносятся только через миграции, в противном случае есть риск потерять данные (у Mysql Workbech переодически крышу сносит при вычислении diff’а структуры). Беру сгенерированый diff и вручную его проверяю, затем переношу его в миграцию, а в последствии применяю ее на тестовом сервере, а уже после тестирования на боевом.

    1. Андрей

      Классная приписка — «до тех пор, пока проект не стартовал». А зачем поддерживать er после старта, если изменения вносятся миграциями?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *