Введение
Я уже писал подобную статью, но она была очень не полной и не снабженной примерами, поэтому я решил взять вторую попытку и попытаться раскрыть данный вопрос наиболее полно!
В данной статье, не будут рассматриваться все тонкости разработки на фреймворках, поскольку это не возможно уложить в рамках одной статьи. Однако, можно достаточно подробно разъяснить те нюансы, которые помогут в выборе для изучения или реализации конкретного проекта. Сравнивать будет 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.
На картике видно что она может. Генератор моделей и 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, уже настроенный под большинсво задач, где мы просто указываем откуда берем исходники, и куда ложим результат.
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 с примерами (не официальная, но хорошая)
Комментарии (98)
GraneDirval
13.04.2018 15:36Yii слишком много позволяет в плане архитектуры, поэтому на нём слишком часто встречается всякой негодности. Вот что мне в нём действительно нравится, так это их queryBuilder. Доктриновский после yii'шного кажется слишком убогим.
dastanaron_dev Автор
13.04.2018 15:39Я бы сказал наоборот, в плане архитектуры — не очень много позволяет. Если это про расположения файлов в проекте. Тут с Ларой они одинаковы. Симфони самый развязанный в плане архитектуры. А по поводу QueryBuilder'a скажу, что чистый доктриновский да, немного сложноватый, за счет непривычности описания в аннотациях, но в Ларе например он переорганизован и ничем не хуже Yii-шного, даже немного похож, поэтому их я даже не сравнивал
SerafimArts
13.04.2018 16:29Симфони самый развязанный в плане архитектуры
Ну… Вот тут я бы поспорил. Слишком много ограничений у симфони. Простой пример: Зарегистрировать UserInterface из секьюрити в контейнере, чтобы потом он мог резолвиться через автовайринг или парам резолвинг. Можно сделать, но это оверинжинеринг и проще сделать фектори (или дёргать токен сторадж).
В этом плане у ларки непосредственно архитектурных ограничений ещё меньше и возможностей больше. У Symfony другое преимущество — он более развязный с зависимостями. Т.е. сами компоненты на порядок гибче, но их и так же на порядок меньше.
BoShurik
13.04.2018 17:32Зарегистрировать UserInterface из секьюрити в контейнере, чтобы потом он мог резолвиться через автовайринг или парам резолвинг. Можно сделать, но это оверинжинеринг
А в чем именно оверинженеринг? Простенькая фэктори + строчка в конфиге
Symfony\Component\Security\Core\User\UserInterface: factory: ['@App\UserProvider', 'get']SerafimArts
13.04.2018 17:44Если честно — у меня вообще вылетел из головы этот способ. Ваша правда.
Ладно, другой пример. Надо для роутов добавить метаинформацию произвольного формата, при этом она должна мерджиться при наследовании (т.е. инклудах). Ну вот простой пример:
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 и надо на эвенты всё вешать, а конфиги выносить в другое место. Ну вот взбрело такое в голову, присобачить миддлвари. Мы же об архитектурной гибкости говорим.
SerafimArts
13.04.2018 16:10Большой функционал работает через фасады и 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 так же указать ссылки на шаблоны для генерации кода.dastanaron_dev Автор
13.04.2018 16:17Спасибо за комментарий. Я не видел смысла вдаваться в дебри смысла работы фасадов, скорее это предупреждение, что придется с этим столкнуться, поскольку ни в Yii2 ни в Symfony этого нет. Но то, что вы описали в комментарии — очень хорошо. Спасибо за дополнение!
SerafimArts
13.04.2018 16:38+2поскольку ни в Yii2 ни в Symfony этого нет.
Сам механизм, который делает всё тоже самое и содержит точно такие же проблемы есть и в Yii и в Symfony.
Сервис локация (фасады и проч)Laravel:
\DB::xxx();
Yii:
Yii::$app->db->xxx();
Symfony:
$container->get('doctrine')->xxx();dastanaron_dev Автор
13.04.2018 17:01Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию
$connection=Yii::app()->db;
Но это как раз через фасады, которые в конфиге задаются. Либо расширением класса ActiveRecord, чем и являются модели. Тут просто не доктрина, поэтому сложно провести аналогию, принцип немного другой.
А в той же ларе или симфони, можно получить низкоуровневый объект PDO
Я не совсем об этом речь вел. Модели я чисто для примера взял. В Ларе например и в роутах используются методы Route::post(/***/), которые по факту не являются статичными. Я в общем о том, что такие явления естьVolCh
13.04.2018 17:10Как-то так:
Yii::$container->get('db');
vs
public function __construct(\yii\db\Connection $db)
SerafimArts
13.04.2018 17:18Сложно сказать. Может я не знаю, но способ получить подключение к базе можно так же через сервис локацию
Вопрос как раз в другом. Как это делать не через эту самую сервис-локацию. Потому что, как я уже описал выше — это крайне плачевный подход для долгоживущих проектов.
Ну вот есть какой-то класс, например database query logger, зарегистрируем его в контейнер (можно же?) по имени "dbQueryLogger". Как сказать проекту, что получая
Yii::app()->dbQueryLogger(или как-то так, поправьте если ошибаюсь) нужно создавать этот объект и прокидывать туда соединение с базой + PSR LoggerInterface.
UPD: О, VolCh ответил на вопрос. Спасибо. А в методы прокидывать так же можно?
VolCh
13.04.2018 17:32Что-то типа
$controller = new class { public function indexAction(\yii\db\Connection $db) { } } Yii::$container->invoke([$controller, 'indexAction']);
? Не уверен, что сработает с анонимным классом, хотя не вижу причин почему нет :)
SerafimArts
13.04.2018 21:42Прикольно. Почитал доку — убедился что это так (кажется, надо было чуть раньше, а не мучать вопросами на хабре? =) ). Даже ребинд параметров завезли для этого invoke (второй аргумент). Ещё чуть-чуть и почти до Laravel дотянет.
SamDark
13.04.2018 17:21По Yii 2 пример ровно такой же :) Инъекция через рефлексию в конструктор поддерживается.
mxuser
13.04.2018 16:25Также хочу дополнить, что Yii2 на самом деле не очень-то привязан к Bootstrap 3. Можно не использовать пакет 'yiisoft/yii2-bootstrap', а вместо него подключить, например, 'digitv/yii2bootstrap4', — и имеем набор классов-виджетов Bootstrap 4
dastanaron_dev Автор
13.04.2018 16:26Безспорно. Можно и свои расширения с виджетами написать и тем же функционалом и юзать например bulma вместо бутстрапа. Но речь то о том, что у него встроенно из коробки, а не установлено из вне.
mxuser
13.04.2018 16:31В данном случае — просто в приложении-шаблоне (https://github.com/yiisoft/yii2-app-basic) в файле composer.json указана зависимость 'yiisoft/yii2-bootstrap'. Если не разворачивать приложение из шаблона, а организовывать структуру проекта самому (ну, или же просто убрать эту зависимость), — пакет не будет доступен. Он не прибит гвоздями, насколько я знаю.
dastanaron_dev Автор
13.04.2018 18:31Да это понятно. Так в любом решении, можно любой пакет заменить на другой или собрать по частям. Речь о работе из коробки, без лишних заморочек и для типовых задач. Когда человек выбирает фреймворк, на котором он будет учиться писать, он не собирается делать Highload проекты и пересобирать фреймворк. До этого еще дойти надо!
mxuser
13.04.2018 18:50Кажется, я неточно выразился.
Я имел в виду то, что Bootstrap3 можно заменить заменой строчки в composer.json. Мне кажется, это — не пересборка фреймворка
webdevium
13.04.2018 16:29В Yii2 есть yii\rest\ActiveController — который позволяет быстро настроить REST FULL API...
Вот как раз REST FULL API он и позволяет делать.
А вот RESTful все таки удобней разрабатывать используя функциональные возможности Laravel
VolCh
13.04.2018 16:38В Symfony (3) из коробки 4, если не ошибаюсь, 4 способа задавать роуты, да и вообще конфиги: php, yaml, xml, annotation. И не понимаю, почему Symfony низкоуровневый фреймворк — уровень у него обычный для современных фреймворков. И не фреймворк laravel построен на базе фреймворка symfony, а фреймворки laravel и symfony построены на базе компонентов symfony, первый в меньшей степени, второй в большей.
dastanaron_dev Автор
13.04.2018 17:07
С первой страницы официального сайта симфони. Означает, что используются не компоненты, а именно фремворк. А Вот Yii использует именно компоненты.
А низкоуровневый — это как аналогия языков программирования. Типа PHP, JAVA, PYTHON языки высокого уровня, а C, C++ или Асемблер низкоуровневые языки. Тут дело в доступности данных низкого уровня (дампы или ячейки памяти, отдельные биты в кластерах), а не в том, как роуты задаютсяSerafimArts
13.04.2018 17:22Symfony — это набор компонентов, который называется "фреймворком". Так же как, например, Illuminate — тоже "фреймворк".
Сборка приложения в симфони называется symfony flex или symfony standard. У Illuminate же называется Laravel. Что тоже называют фреймворками, хотя это только сборка.
VolCh
13.04.2018 17:56https://github.com/symfony/framework-bundle — вот фреймворк симфони
https://github.com/laravel/framework — вот фреймворк ларавелKoloBango
13.04.2018 18:58github.com/symfony/symfony — вот фреймворк симфони.
А github.com/symfony/framework-bundle — это FrameworkBundle использующийся в составе фремворка
Symfony более низкоуровневый фреймворк
Имхо автор не имеет реального опыта работы с симфони и краем глаза увидел что компоненты симфони используются в Laravel и т.д… Symfony фреймворк в том же смысле что и Laravel позволяющий реализовывать хотя бы тот же MVC паттерн
VolCh
13.04.2018 17:58Так чем у симфони уровень ниже чем у ларавеля? какие, например, абстракции не предоставляет симфони?
dastanaron_dev Автор
13.04.2018 18:27Ай, ну как же не понять то. Низкоуровневый — не значит хуже или что то невозможно реализовать или чего-то не предоставляет. Низкоуровневый язык программирования означает, что ты можешь работать с данными не на уровне объектов и чисел и строк, а на уровне дампов памяти, битов, положения битов в кластере и тому подобные вещи. В аналогии с фреймворками я имел ввиду, что для Симфони ты будешь больше писать ручками, для осуществления каких-то типовых задач, которые в свою очередь в Ларе и Юии имеют готовые решения.
VolCh
14.04.2018 10:03Так каких "каких-то"? У каких типовых задач по разработке на PHP нет готовых решение в symfony и есть в yii/laravel?
В Symfony есть абстракции над http и сессиями, роутинг, шаблонизация, кеширование, работа с формами, валидация, работа с ФС, контроль доступа, DI, i18n, l10n и переводы, конфигурация, сериализация, работа с процессами ОС, свой http-клиент и работа с DOM, бридж к ORM, бридж к свифтмейлеру, бридж к пхпюнит, бридж к монолог, бридж к твиг, средства отладки и профилирования. Что ещё нужно от фреймворка?
Генераторы не в счёт, они не являются частью фреймворка как каркаса приложения, они часть экосистемы вокруг каркаса.
Akdmeh
13.04.2018 17:31Ну и замечание: многие вещи в плане разделения frontend/backend будут сделаны в Yii 2.1. Как минимум — отказ от привязки к jQuery. Разработчики прекрасно знают о подобной исторической проблеме архитектуры и пытаются ее постепенно решить по мере возможностей.
Но в плане разработки сайта на коленке с простой админкой — это очень сильная сторона Yii. По сути можно сделать на нем простой блог за 30 минут и это не преувеличение.
cawakharkov
13.04.2018 18:32Интересно, с каких это пор в симфони стали отсутствовать инструменты для решения небольших типовых задач?
А если выбирать из 2х зол, я бы выбрал меньшую — Laravel.dastanaron_dev Автор
13.04.2018 18:41Приведу пример. В Симфони есть генератор готовых интерфейсов? Встроенный удобный сборщик фронтенда как у Ларавел? Помельче: хелперы для работы с конфигами, или какими-то данными. А интерфейсы для данных — это вполне типовая задача.
BoShurik
13.04.2018 18:43В Симфони есть генератор готовых интерфейсов?
https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html
Встроенный удобный сборщик фронтенда как у Ларавел?
dastanaron_dev Автор
13.04.2018 18:46Разговор про с коробки! Доставить можно все что угодно. И в Симфони правильно делают что не ставят в коробку. В последней версии вообще много чего выпилили с того, что было раньше, все можно поставить, но отдельно, и по мере надобности. Мне нравится такой подход. Но разговор шёл про «из коробки». Здесь не о чем спорить. Для многих типовых решений есть куча отдельных библиотек написанным самими SensioLab и сторонние решения.
symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html
Это совсем не то, что делает Yii. Этот генерирует только php файлы с классами, а у Yii это и модели и контроллеры сразу с данными и готовое сверстанное представлениеBoShurik
13.04.2018 18:50https://github.com/symfony/website-skeleton/blob/4.0/composer.json
"require": { // ... "symfony/webpack-encore-pack": "*", // ... }, "require-dev": { // ... "symfony/maker-bundle": "^1.0", // ... },dastanaron_dev Автор
13.04.2018 18:58Мейкер был. А вот вебпака вроде не было, до недавних пор. Может я ошибаюсь, но это все равно не то. Мейкер тут точно такой же как в Ларавел, точнее в Ларавел он заимствован из симфони скорее всего. А вебпак все равно надо настраивать, как с миксами легко не получится. Но это не в минус, это как раз больше к свободе действий.
Не поймите меня не правильно. Симфони я очень уважаю. Но для типовых проектов, которые мне приходилось делать быстрее сделать на Ларе или Юии. Симфони лучше подходит для планирования хорошей архитектуры и мощных нагруженных проектов. Для толстых проектов, совмещающих в себе кучу мелких, я бы бесспорно выбрал Симфони. А если писать что-то типа Алибабы, Ебэя или Что-то еще более крупное. Лучше вообще избегать фреймворков, поскольку тут очень важно продумать свою разумную архитектуру, чего не делает один человек. Не думаю что Гугл или Яндекс пишут на каких-то фреймворках, скорее разрабатывают свои. Но это лично мое мнениеcawakharkov
13.04.2018 19:02Сейчас большинство проектов делается согласно принципу “Api first”. А в нагружённом проекте вообще всегда зоопарк технологий а не фреймворк.
BoShurik
13.04.2018 20:57Это совсем не то, что делает Yii.
Laravel тоже так не умеет, на сколько я помню, но его вы почему-то включили в обзор
hudson
13.04.2018 21:34Symfony начиная с версии 4 как раз следует парадигме «доставь все что тебе нужно». Чем-то напоминает Flask из мира python. На старте это готовый микрофреймворк, но собрать из него можно что угодно.
Было ли это хорошим решением — время покажет. Лично мне нравится, хоть и непривычно что Doctrine и Twig по умолчанию отсутствуют.
cawakharkov
13.04.2018 18:50Что такое генератор интерфейса?
Для фронта — есть и любой вешний без проблем подключается. Что должны делать эти хелперы а главное зачем? Тот же вопрос про данные.
BoShurik
13.04.2018 21:01Помельче: хелперы для работы с конфигами, или какими-то данными.
Что вы под этим имеете в виду?
cawakharkov
13.04.2018 18:51Где вы видели, что в проекте используется только то, что есть в самом фреймворке?
dastanaron_dev Автор
13.04.2018 18:59Нигде не видели)
cawakharkov
13.04.2018 19:03Тогда к чему такая привязка к инструментам из коробки?
dastanaron_dev Автор
13.04.2018 19:46Потому что если сравнивать. То возможности самих фреймов. А если говорить о различных надстройках, то вообще можно придти к выводу что все имеют одинаковые возможности с разной реализацией просто.
VolCh
14.04.2018 10:20Сравнивать можно и нужно не то, что из коробки (особенно если коробок много по факту, скажем различные edition типа web-edition, api-edition и т. п. или full-edition, standard-edition, micro-edition), а то, что предоставляет вендор прежде всего. Если в доках фреймворка X написано про фичу Y "перед использованием подключите Y с помощью
composer req x/y", то это не повод исключать из сравнения.
calg0n
13.04.2018 21:28Сразу предупрежу вопрос о том, почему не рассматриваем Symfony.
Ерунда какая-то написана. Мы используем Symfony и в крупных и в мелких проектах и никаких костылей вроде собственных фреймворков не пишем.
Дело в том, что Symfony более низкоуровневый фреймворк, который чаще берут для основы в крупных проектах, например таких, как написание собственного фреймворка для разработки.
Вы вероятно имели в виду бандлы, а не сам фреймворк. Из отдельных бандлов/либ да, можно набросать свой собственный фреймворк (в этом собственно прелесть модульной архитектуры) если уж очень колется, но только зачем? :)
Его в принципе нельзя сравнивать с Laravel и Yii2, так как они используют его компоненты в своих реализациях.
Ну вот вы сами ответили на свой вопрос.
sayber
13.04.2018 21:34+1В 2015г. я бы еще обратил внимание на Yii.
На данный момент, не вижу в нем хотя бы одного плюса.
Правда я фанат Symfony DDD/CQRS/Bus/EQ… Потому мое мнение совершенно бесполезно.
На тему крупных проектов, видимо автор застрял в 2015-2016гг. и не знает о существовании Symfony 4.
Соответственно, считать данный пост серьезным, совершенно нельзя.hudson
13.04.2018 21:38+1Я бы отмотал еще лет 7 ) Если и сравнивать Yii то с Symfony 1.x, ZF1.x (год 2007-2008й). Кстати у Symfony тогда был админ-генератор из коробки))
sayber
13.04.2018 21:40Да, был. Но я в то время на Zend писал и осваивал Yii, который был в тренде.
Но сейчас, выбор мой SF, но если смотреть на другие, то конечно laravel.
Причина проста — организация кода, архитектурный принцип и конечно ioc.
В добавок, удобно реализовать DDD. Хотя тоже надо будет поковыряться и написать обработчик для входящих данных, что бы использовать геттерыhudson
13.04.2018 21:46Я тогда выбрал Symfony (из-за схожести с RoR, который тогда тоже был в тренде, но не только — делал несколько небольших проектов то на одном, то на другом фреймворке, сравнивал грабли). И не пожалел, вторая версия, хоть поначалу и казалась сложной, повернула мозги в правильном направлении.
Anton_Zh
14.04.2018 07:04Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного, так что ниша Yii/Laravel довольно большая.
IoC есть и в Yii и в Laravel. В Yii в основном практикуется ServiceLocator. например вызов Yii::$app->get(); или Instance::ensure() в конструкторе хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка, а это не так уж нужно если не пишешь библиотеку.VolCh
14.04.2018 10:13Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного
хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворкаТо есть возможность роста проекта настолько, что DDD начнёт приносить пользу вы априори исключаете, гвоздями прибивая классы проекта к фреймворку, на котором сложно работать с DDD?
Anton_Zh
14.04.2018 15:13По такой логике надо во все проекты DDD закладывать «на вырост», я не могу с этим согласиться, «на вырост» часто оказывается вредным.
VolCh
14.04.2018 15:29Я не про закладывание DDD, про непривязывание намертво основных частей приложения к фреймворку, который выбран здесь и сейчас. Закладывание возможности сменить фреймворк или его мажорную версию.
sayber
14.04.2018 14:28DDD — любой проект, где существует серьезная бизнес логика. Проекты, где важен бизнес а не ЧСВ разработчика.
Сначала реализуется бизнес-логика, которая не зависит от приложения, затем делается остальное.
Вот главная цель DDD.
Конечно, применять в мелких сайтах и петпроектах не имеет смысла.
Но я не говорю о таких проектах, их можно реализовать хоть на html и пару микросервисов. Я даже не считаю подобные проекты работой.
Т.е. вывод прост, вы не представляете что такое DDD и для чего.
Или просто не работали над серьезными бизнес-проектами с миллионными инвестициями.Anton_Zh
14.04.2018 14:37Главная цель DDD это устранение сложностей с пониманием предметной области и создание реализации, максимально близкой к модели предметной области, чтобы ее удобно было понимать и поддерживать.
По вашему серьезные проекты невозможны без DDD?) Большинство проектов на Yii не сделаны по DDD, их вы тоже не считаете работой?) Жгите дальше.sayber
14.04.2018 14:49+1Нет, почему же.
Можно написать хоть обычными функциями на PHP4 (делал банковскую CRM в 2007г.).
Вы мне напомнили людей с развлекательных сайтов, которые читают первую строчку, затем среднюю и последнюю.
Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
Я не писал, что невозможны серьезные проекты без DDD.
Вы как западные политики, придумываете то что вам удобно.
Почему для слепых котят, надо все пояснять и выделять жирным текстом?
Конечно, применять в мелких сайтах и петпроектах не имеет смысла.
Но я не говорю о таких проектах, их можно реализовать хоть на html и пару микросервисов. Я даже не считаю подобные проекты работой.Anton_Zh
14.04.2018 15:21Вообще — я не говорил, что YII нельзя использовать и это полное дерьмо.
Я не писал, что невозможны серьезные проекты без DDD.
Вы как западные политики, придумываете то что вам удобно.
Почему для слепых котят, надо все пояснять и выделять жирным текстом?
Извините, я неправильно понял ваш комментарий.
YaRobot
14.04.2018 14:54Не вижу что кто-то писал, будто без ДДД невозможно реализовать крупное программное решение.
Доменый слой существует для реализации логики в отрыве от данных и приложения.
Вы пишите логику, основываясь на требованиях бизнеса. Домен, дает прекрасную возможность, подстраиваться под веяния бизнеса.Anton_Zh
14.04.2018 14:59А без DDD вы логику на основе чего пишете?
YaRobot
14.04.2018 15:11Как обычно, бестпрактик.
Но это к сожалению не дает возможности, быстро перестроить логику, если что то кардинально изменится.
Соответственно это время и деньги бизнеса.
Если вас смутила фраза
Вы пишите логику, основываясь на требованиях бизнеса.
То тут имелось ввиду, что в ДДД пишут, не именно вы =)
Пишу статью, образ речи сохраняется и в комментариях =)Anton_Zh
14.04.2018 16:16Я хотел сказать, что любые приложения всегда пишутся по требованиям бизнеса, DDD здесь не монополист. Да, по сравнению с обычными приложениями, в DDD код более абстрактный и иногда легче по нему понять сложную бизнес-схему. Но это актуально только для реально сложных проектов, там где логика простая, DDD привносит больше сложности, чем снимает. Основная цель DDD борьба со сложностью, но для этого нужно сначала убедиться в том, что эта сложность действительно есть и она будет доставлять проблемы.
VolCh
14.04.2018 15:37Без DDD вы, грубо говоря, не выделяете бизнес-логику в отдельный слой, независимый ни от чего кроме бизнес-требований. Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и "моделями" (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в "моделях", а не в контроллерах.
Выделение бизнес-логики в отдельный независимый слой в общем случае не только в случае DDD может применяться, но на практике если видишь такое выделение, то и другие технические паттерны DDD замечаешь почему-то.
Anton_Zh
14.04.2018 16:05Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и «моделями» (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в «моделях», а не в контроллерах.
Ну в таком случае можно сказать, что в DDD-проекте она размазана между сущностями и сервисами, и хорошо, если большая часть в сущностях, а не сервисах, чтоб не получились анемичные сущности.
VolCh
14.04.2018 19:27Существенное отличие между нашими фразами — в вашей нет слов "унаследованного от базового класса". В DDD бизнес-логика размазана по слою бизнес-логики и ни от чего не зависит. В типичном Yii/Laravel приложении бизнес-логика размазана между моделью, совмещающей по определению бизнес- и инфраструктурную логики, и контроллерами, реализующими по определению часть UI-логики. И, главное, и там, и там она зависит от классов, предоставляемых фреймворком. Захотите поменять фреймворк (ну или проапгрейдить на мажорную версию) — придётся разбираться где бизнес-логика, а где UI или инфраструктурная.
На актуальных версиях Yii/Laravel/Zend/Symfony можно писать как приложения в которых бизнес-логика отделена от всего остального, так и приложения в которых практически вся кастомная логика в контроллере, но почему-то на Zend и Symfony отделяют гораздо чаще, чем на Yii/Laravel. Как мне кажется, это не просто случайное стечение обстоятельств, а вполне сознательное поощрение того или иного стиля ведущими разработчиками того или иного фреймворка.
Anton_Zh
15.04.2018 02:25Я думаю, что это абсолютно нормально, когда для решения какой-то задачи берется популярный, поддерживаемый фреймворк и код зависит от него. В этом ничего плохого я не вижу и считаю это нормальным. Да, при смене мажорной версии придется приложить усилия, заменить какие-то вызовы, базовые классы, отрефакторить проект. C DDD эти усилия прикладываются наперед, но несколько в другом виде — абстракции. домена. Но и это спасет от рефакторинга лишь часть проекта. При замене фреймворка/мажорной версии все равно придется много переделывать. Инфраструктурный слой все равно придется переписать, а этот слой чаще получается даже намного толще доменного.
Я предпочитаю не закладывать наперед возможность смены фреймворка/мажорной версии, так как это порождает много абстракций, которые замедляют и усложняют разработку (надо больше думать для выделения хороших абстракций), чтобы потом облегчить гипотетическую смену фреймворка, которая может и не понадобиться вовсе. Некоторые проекты на Yii1 спокойно продолжают работать.
Фреймворконезависимость обходится дорого, она добавляет забот. Помимо реализации требований, приходится решать задачи по абстракции.
Да, иногда, она оказывается полезной, но я нахожу такие ситуации довольно редкими.
Anton_Zh
14.04.2018 14:54Правда я фанат Symfony DDD/CQRS/Bus/EQ…
Вот, сразу виден фанатизм. Он ослепляет.
Я пробовал применять DDD в проекте. Что получилось — то же самое что и было без DDD, только работы больше по абстракции домена. Кода стало реально больше. Оверхед был налицо, поэтому для себя я сделал вывод, что DDD нужно применять только тогда, когда есть проблемы коммуникации(!), домен реально сложный и нетиповой.
О недостатках DDD в википедии
sayber
14.04.2018 15:03Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.
Доработали доктрину, реализовали сериалайзер и маппинг бандлы.
На данный момент, проект полностью оторван от приложения. Т.е. домен можно использовать в любом другом месте, подгрузив только нужные зависимости.
Слой приложения, полностью отдельный и не зависит от домена.
Вместе же, это реализует API для HL++ проекта.
Оверхеда какого либо нет. Правда это заслуга хорошо продуманной архитектуре и то о чем я писал выше.
Я вам открою секрет, на текущий момент, я больше фанат Golang и laravel. Но это только в отрыве от бизнеса.Anton_Zh
14.04.2018 15:10Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.
4 месяца без кода, ну это большой риск. И что прототипов даже не писали?
На данный момент, проект полностью оторван от приложения. Т.е. домен можно использовать в любом другом месте, подгрузив только нужные зависимости.
Вот именно, что можно, но нужно ли? Вам это дало какой-то профит, если не секрет, какой? Повторно использовали домен в другом проекте? Так он же уникальный, разве нет? В чем именно получилась реальная выгода, если не секрет?sayber
14.04.2018 15:23Нет. Блок схемы в основном. Продумывали алгоритмы.
У нас было время, т.к. проект уже работал (кстати на YIi частично), но он не отвечал двум основным требованиям. Это нагрузка (на 50 обращениях уже не вытягивал именно PHP, не БД. До нас делали по доке проект), вторая проблема, это изменения поведения внешних клиентов которым поставляются данные (booking.com, trivago и др. букинг товарищи).
Время дали год для команды. Надо было придумать и реализовать проект с возможностью быстрой перестройки под тот или иной проект. Особенно это стало хорошо заметно на фоне санкций и нового закона о данных.
Профит — я уже сказал по сути. Быстрая смена работы под определенные бизнес-решения. Домен используется и в др. проекта, как вы верно заметили. Домен не совсем уникальный, он имеет модели, репозитории, логику для определенных вещей букинг бизнеса, что в 90% случаев одинаково.
Для использования домена в другом проекте (условие только SF), надо подменить для своих нужд хендлеры, если это требуется и/или объекты ответа заменить.
Слой приложения пишется свой, у каждого свои потребности.
VolCh
14.04.2018 15:40В каком плане "то же самое"? Если работы по абстракции больше, то значит не то же самое, а абстракция сильнее, нет?
Anton_Zh
14.04.2018 15:59«То же самое» — имеется ввиду реальная работа, которую выполняет код. Да, абстракция стала сильнее, но внедрять новые функциональные возможности, как ни странно, стало сложнее. Приходится думать, как новое ляжет на существующие абстракции, а если не ложится, приходится их модифицировать вместе со всем соответсвующим инфраструктурным кодом. Да и просто больше файлов надо просмотреть и отредактировать.
Сначала меня DDD увлек, я думал, он мне поможет упростить работу, а на практике оказалось нет. Проект не настолько сложный и большой, команда 3 человека в одном офисе.
calg0n
13.04.2018 21:45Даа. Админ-генератор был сказка. Мы вот в sf4 юзаем EasyAdmin и плюёмся :(
Я так понимаю кроме жирной Сонаты и EasyAdmin больше вариантов нет?sayber
13.04.2018 21:48Если и есть, то хуже по качеству.
Хотя я особо не искал.
SF в 99% используется для реализации API, остальное swagger + экспорт в postman.
hudson
13.04.2018 21:48Нормальных я не видел. EasyAdmin использую для чего-то совсем простого, в остальных случаях пишу свои решения. Sonata, при всем моем уважении к труду сообщества, слишком медленная и переусложненная. Я отказался от ее использования после долгих лет мучений… )
Samouvazhektra
13.04.2018 22:48Работа через фасады, большинства обширных классов Laravel. Такое сложное предложение, я поясню! Дело в том, что во многих классах фреймворка используется динамическое создание свойств и методов, в зависимости от каких-то условий.
Проще привести пример. Мы объявляем класс модели работы с базой данных, которая является расширением стандартного класса Illuminate\Database\Eloquent\Model, в котором нет статических методов where, select и т.п., но на самом деле они есть и ими можно пользоваться. Вот такие чудеса. Дело в том, что такие методы образуются из так называемых фасадов, которые считывают обычные методы класса и превращают их в статические. А свойства получаются путем обращения к базе данных.Автор вообще не видит разницы между фасадами и магическими методами? Статью очень трудно воспринимать, так как автор явно поверхностно знаком с обоими фреймворками.
Плюс Yii2 — в том что он очень лоялен к новичкам, можно генерацию из интерфейсов делать, без консоли, можно минимум js знать, тонны виджетов на каждый чих; и он же — большой минус так как тормозит развитие и изучение сопутствующего стека, оставляя зацикленными на jquery-bootstrap
И очень не хватает для Yii2 аналога laracast
Anton_Zh
14.04.2018 06:56Да, Yii/Laravel + VueJs на мой взгляд сейчас очень актуальный и востребованный стек.
Сам работаю с Yii, очень удобно.
Про механизмы доступа к данным что-то ничего не написали.
OnYourLips
14.04.2018 10:13Большой функционал работает через фасады и IDE-системы не видят методов и свойств в некоторых классах, показывая предупреждения
Вас никто не заставляет использовать фасады. В Laravel есть замечательный DI с автовайрингом и это предпочтительный способ связывания.
Изучается немного сложнее Yii2
С моей точнки зрения все как раз наоборот, из-за огромного количества обучающих материалов по Laravel, рассчитанных на новичков. Есть даже интерактивные курсы, где в процессе обучения надо писать код.
А по поводу QueryBuilder'a скажу, что чистый доктриновский да, немного сложноватый, за счет непривычности описания в аннотациях
Описывайте в yaml, так удобнее.
ivorobioff
15.04.2018 00:36И все же, не вижу проблем использование Symfony — он вполне прост из коробки, легко можно построить обычное приложение без особых усилий… думаю что страшилок про Symfony надо меньше читать и тогда все будет окей…
VolCh
15.04.2018 23:50Скорее впечатления от первых релизов второй ветки. Аутентификации с авторизациями чего стоили, да и в 4, наверное, самая сложная тема для начинающих.
VolCh
16.04.2018 00:15С лета 2013-го до лета 2017-го моей основной задачей была поддержка и развитие проекта на symfony 1.4. Он был популярным и поддерживаемым на время старта проекта. И процентов на 90 уверен, что он работает до сих пор, хотя и ведутся работы по уходу с него. Что я могу сказать: была бы там логика отделена от фреймворка (считая doctrine1 частью symfony 1) — не было бы острой нужды в уходе с него. Минимум годовую зарплату я получил за борьбу с сильной связанностью бизнес-логики и фреймворка. Там и других косяков в архитектуре хватало, и сам я немало костылей написал под убеждением «ещё пара месяцев и так или иначе развитие остановится» буквально с первого дня работы, но основная проблема была именно в отсутствии изоляции от фреймворка и orm. По самым моим пессимистичным оценкам, пару человеко-месяцев выделенных летом 2013-года на изоляцию, окупились бы только за счёт моих задач к лету 2017-го многократно.
hudson
Ни в коем случае не ведитесь на «простоту» Yii! В качестве первого фреймворка ни в коем случае не рекомендую — плохому научитесь. Сделайте по простенькому проекту на Laravel / Symfony / ZF и выберите тот что понравится. Не нойте что сложно (не сложно!) — это окупится с лихвой в будущем.
OKyJIucT
Ваше заявление звучит примерно так: «Если вы хотите использовать простой инструмент, используйте вместо него сложный».
Вы советуете начинать изучение фреймворков с тех, что сложнее, и велика вероятность, что человек не осилит, и пойдет дальше говнокодить на коленке. Как по мне, то лучше сначала начать с простого, постепенно усложняя, чем сразу нырять в омут с головой.
hudson
Я вкладывал немного другой смысл — «не гонитесь за ложной простотой». Луше вложить немного усилий в самообразование и получить хороший старт для дальнейшего роста.
И да, я более чем уверен что меня мало кто послушает. Проще «говнокодить на коленке» на Yii, чем задумываться над тем, почему же в шаблоне нельзя делать «SomeModel->listAll()» и многие другие славные вещи…
Yii не отвратителен, но изначально (в том числе в документации) он дает массу вредных советов и не запрещает разработчикам стрелять себе в ногу, там где им хочется.
OKyJIucT
С этим я согласен, если бы я изначально по такому пути пошел, то сэкономил бы годы. Даже если бы я прочитал эту статью на заре становления своей карьеры, то вряд ли прислушался. Хочется же побыстрей, все и сразу.
hudson
В точку, менторство у нас не в чести, увы. Сколько хороших советов мне не дали в свое время… )))
dastanaron_dev Автор
Ха, про выстрел в ногу точняк. Это даже с виджетами для фронта можно соеденить. Соберешь фронт себе на бек и будешь сам его потом палкой ковырять, а когда проект разрастется и потребуется разделить обязанности, будут большие сложности, вот это и есть выстрел себе в ногу, поэтому я и назвал это и минусом и плюсом
hudson
Может я слишком категорично высказался, но в последнее время много проектов на Yii пришлось просмотреть — везде схожие ошибки. Наболело. И просматривая список вакансий постоянно вижу именно Yii. Да, просто, да быстро. Но чтобы тянуть на нем более-менее серьезный проект, на старте нужен серьезный опыт.
SerafimArts
Тоже самое и в случае Laravel происходит. Слишком много он позволяет. А новички хотят скорее начать, не понимая к чему это приведёт в будущем.
Да вот те же самые фасады. Мало кто понимает, что их стоит использовать лишь в качестве хелперов, например в консольке или миграциях, а для бизнес-логики только DI. А потом открываешь какой-нибудь проект и видишь методы контроллеров по 500 строк каждый, которые при этом ещё и копипастятся. Хотя бы сервисный слой для этого? Какой сервисный слой? Не… не слышал =)
Кажется, что это «бич» любого решения с низким порогом входа, но склонен согласиться с тем, что в случае Yii — там на порядок сложнее вывести такой проект в адекватное состояние. Хотя тут я не слишком объективен.
SamDark
То же самое происходит вне зависимости от фреймворка. Если у вас первым был Yii и вы прошли там по всем граблям, вы не будете на них наступать в том же Laravel и наоборот.