Comments 87
ps: А что не так с ubiquity, почему нет в списке?
По сути российские программисты на PHP — прямые конкуренты разработчиков из Индии и данный комментарий весьма полезен: позволяет понять, на что стоит обратить внимание при изучении
CakePHP используют норм в Японии и США. У нас нет. Yii используют много где, но у нас, как раз, это ярко выражено. А так, если по глобальной популярности смотреть, то да, Laravel на первом месте. Symfony сильно меньше, но тоже немало.
Зато кто-то плюсов статье наставил…
Laravel — это бесплатный опенсорсный PHP-фреймворк, получается в статье остальные платные?
А есть ли в принципе платные php-фреймворки?
Интересно, т.е. по вашему Yii и Laravel достойны 1 и 2 места?
Мне всегда казалось, что рейтинг должен начинаться с Symfony и выглядеть примерно так:
Symfony
Laravel
Yii 2
Zend
и тд
Мне доводилось программировать на каждом из них, причем во всех мажорных версиях начиная с первых. В каждом из них я смотрел под капот в исходники.
ИМХО, я бы не ставил Symfony так далеко.
Laravel хорош для новичка — все из коробки, просто развернуть, просто работать — но как только появляется необходимость что-то поменять в ядре — жизнь боль, Job's если поменять параметры конструктора — тоже валяться на раз два. При работе с миграциями — необходимо быть предельно осторожным.
Symfony — монстр с решениями на все случаи жизни, но на его изучение также придется потратить пару жизней.
Zend — раньше жил только за счет его форса ZendFoundation и был жутко неудобной страшной штукой. Сейчас (Laminas) даже не смотрел.
Yii — Собран на коленке для создания проектов на коленке, после laravel покажется жутко не удобным.
Phalcon — был актуален на php5.6 так как работал намного быстрее всего что было тогда — за счет того что ядро скомпилировано как плагин php. При php >= 7.0 уже почти не имеет смысла так как из самого php выжали почти все возможное и теперь дожимают остальное.
Все остальное — уже жуткий legacy — проще с нуля собрать свой фреймворк с помощью php-di
github.com/symfony/symfony/tree/5.2/src/Symfony/Bundle/SecurityBundle/Resources/config
А если вы про свой код (который под вашим управлением), то вы были вольны держать его в php формате уже несколько лет как. Если вы держали его в ямле — ну, значит, видимо, вы приняли такое решение зачем-то.
symfony.com/doc/2.8/configuration/configuration_organization.html
на вскидку в документации к 2.8 уже были вкладки yaml\xml\php в документации, так что можно было оформлять конфиги в любом удообном вам формате
Аннотации — никто никогда не заставлял пользовать тоже на самом деле. Все можно описывать в тех же конфигах.
Поэтому и говорят, что он мощный. Просто далеко не все осознают что поменять можно почти все.
О чем и говорит TheCluster. Этого уже нет. Вот, к примеру, конфиг для демо приложения. Он отличается от дефолтного всего несколькими строчками.
Ну а что касается аннотаций, то их можно не использовать: php, yaml, xml — выбирай не хочу
Можете писать на php, вот ещё не закоммитил даже роутинг для прототипа:
<?php declare(strict_types=1);
use App\User\RegisterFormController;
use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;
return function (RoutingConfigurator $routes) {
$routes->add('register', '/{_locale}/register')
->methods(['GET'])
->requirements(['_locale' => 'uk|ru'])
->controller([RegisterFormController::class, '__invoke']);
};
На аннотациях/атрибутах явно лучше было быНа аннотациях/атрибутах явно лучше было бы
Так можно и на php лучше сделать. Вот пример из laravel:
Route::get('register', [RegisterFormController::class, 'invoke'])
->name('register');
А локаль вынести на уровень выше, так как она нужна для большинства роутов.
А разве такие вызовы обязательно статические? Массив [$className, $method] не в каждом роутере будет восприниматься, как callable. Такая запись удобна тем, что IDE это понимает и не ругается, что у контроллера есть невызываемый публичный метод. Но под капотом сначала проверяется возможность получить контроллер из контейнера, и, если такая возможность есть, то роут-диспетчер получит контроллер из контейнера и вызовет соответствующий метод. А если контейнер отвечает, что не знает о таком контроллере, то тогда уже передает вызов массиву как статик методу.
Или я не правильно понял статик колл?
А, ну в этом случае используется фасад. Можно и без статики сделать:
<?php
$router = app()->get(\Illuminate\Routing\Router::class);
$router->get('register', [RegisterFormController::class, 'invoke'])->name('register');Но в проектах такого я не встречал
app()-> — ничем не лучше в данном случае ) наличие таких вещей означает, что у вас в памяти где-то есть глобальный или статический объект, который вы получаете вызовом данной функции для доконфигурации. Фактически это синглтон. Чем плох синглтон я надеюсь можно не объяснять.Вообще да, но мы же сейчас про конфигурацию роутинга говорим. Можно и в сервис-провайдере определить конфигурацию роутинга, но я не видел, чтобы так делали. Во всех laravel-проектах, с которыми я сталкивался, роутинг конфигурируется через фасады, будь они не ладны
Вообще да, но мы же сейчас про конфигурацию роутинга говорим
Вы так говорите, как будто в остальных местах лара проповедует SOLID
laravel.com/docs/8.x/validation#manually-creating-validators
Фасад на фасаде.
Во всех laravel-проектах, с которыми я сталкивался, роутинг конфигурируется через фасады, будь они не ладны
Поэтому для меня laravel — это некоторый yii на стероидах. Да, модные компоненты. Но статика, магия, рантайм конфигурация…
Вы так говорите, как будто в остальных местах лара проповедует SOLID
Нет, я говорю лишь о том, что в ларе многие вещи можно сделать по SOLID.
Фасад на фасаде.
Да, и мне ужасно не нравится эта концепция. И не нравится, что документация не рассказывает о best practies.
Поэтому для меня laravel — это некоторый yii на стероидах. Да, модные компоненты. Но статика, магия, рантайм конфигурация…
ППКС
Если речь о файлах web.php и api.php, в которых из коробки описываются роуты, то в них переменная $router доступна без объявления.
Только для IDE приходится ее тип в начале файла прописывать:
/** @var \Illuminate\Routing\Router $router */И чем это лучше?
Рассказывает фреймворку какой метод какого контроллера дернуть, когда придёт GET запрос /ru/register и как сформировать урл для роута с именем register
Аннотации/атрибуты и задаются на уровне контроллера. Есть, правда, минус — поиском по исходникам сложно понять какой контроллер за обработку конкретного урла отвечает. Ну и формально нарушается SRP — контроллер должен знать что-то о роутах, на которые он должен откликаться, управлять конфигурацией фреймворка по сути
>Laravel хорош для новичка
О да, то, что новички вытворяют на Laravel, такого ужаса на Yii мне не встречалось. Кстати, документация у Yii2, как по мне, более удобная и информативная.
в этом решили сделать его форк на Laravel, сделав упор на оптимизацию, переписав логику, упростив процессы и после Yii2 Лара просто вызывает удивление. Yii2 из коробки убирает возню с маршрутами, с генерацией CRUD, простое введение ролей в проект за счёт RBAС, валидация простая и понятная, шаблоны в плане синтаксиса как-то поаккуратнее шаблонов блейда выглядят. В Ларе мы успели и с путями покуролесить, и с валидацией поморочились, и CRUD-генератор, который варит контроллеры/модели/формы, тоже искали. В Ларе строка текста, которая имеет переводы, выглядит как __('admin.Enter name'), к нам подходил джун, спрашивал, что это за «магические методы у нас в формах, я не знаю, как такое гуглить»))
Да, мы потом со всем разобрались и настроили, но Yii2 из коробки в плане документации и удобства выглядит как зрелый, цельный фреймворк, а Лара как хайп-фреймворк, который дёргал с миру по нитке + такое ощущение, что эти люди страшно скучали по разработке на javasript)
п.с: хотя у этих фреймворков, скорее, разные назначения и возможности, но вот как раз в плане удобства Yii2 как раз, имхо, максимально удобен, а на основные вещи есть даже актуальная документация на русском
решили сделать его форк на Laravel, сделав упор на оптимизацию
Вот тут я очень растерялся. Не самый логичный выбор, на мой взгляд.
В Ларе строка текста, которая имеет переводы, выглядит как __('admin.Enter name')
Ещё с 4 версии PHP было расширение для локализации gettext, так вот в нём был оператор _($string). Скорее всего оттуда и растут корни. Опять же, никто в ларе не заставляет использовать __(), можно использовать более понятное trans(), учитывая что
<?php
# vendor/laravel/framework/src/Illuminate/Foundation/helpers.php
// ...
if (! function_exists('__')) {
/**
* Translate the given message.
*
* @param string|null $key
* @param array $replace
* @param string|null $locale
* @return string|array|null
*/
function __($key = null, $replace = [], $locale = null)
{
if (is_null($key)) {
return $key;
}
return trans($key, $replace, $locale);
}
}
// ...
А можно инжектить Illuminate\Contracts\Translation\Translator. А в шаблонах можно использовать диркективу @lang(). Вряд ли фреймворк виноват в том, что вы в своем проекте выбрали тот путь, который ваши джуны теперь не могут гуглить.
Когда появилось время — решили это переписать, хотели фреймворк на актуальной версии php, который активно развивается, посмотрели, что на рынке ходовое, что на stackOverFlow активно обсуждается и, по сути, всё свелось к Symphony или Laravel. В итоге выбор пал на Laravel — его охотно хотят на рынке проектов и вакансий, на нём делается много проектов, сам фреймворк активно обсуждается на стековерфлоу, развивается, выходят релизы и полезные дополнения + он нам показался проще для ознакомления, чем, например, Syphony
2) про gettext() вы совершенно правы, просто если гуглить «навскидку», то запросы вида «два подчерка» «php two underscores» выдают много результатов про магические методы
Yii2 из коробки убирает возню с маршрутами, с генерацией CRUD, простое введение ролей в проект за счёт RBAС
Это достоинство выльется в фатальный недостаток, когда окажется, что приложение должно выполнять требования бизнеса. Шаг влево — и начинаются велосипедостроения, а палки в колеса подкинут излишне связанные части ядра.
Фреймворк должен давать только прочный скелет, но не определять что и каким образом будет на нем реализовано. Увы, что Yii, что Laravel в пролете по этому параметру.
. В Ларе строка текста, которая имеет переводы, выглядит как __('admin.Enter name'), к нам подходил джун, спрашивал, что это за «магические методы у нас в формах, я не знаю, как такое гуглить»))
а в чем проблема отправить джуна читать оф доку перед началом работы?
Ну из остального не всё legacy. Slim вполне себе норм, на нём и php-di всё же проще собрать приложение, чем на php-di с нуля.
Zend — раньше жил только за счет его форса ZendFoundation и был жутко неудобной страшной штукой. Сейчас (Laminas) даже не смотрел.Первый зенд был ещё более-менее нормальным, если не брать во внимание длинющие имена классов. Он был типа «фундаментальный», с каркасом но без готовых решений, навязываемых фреймворком. Мне такой подход даже импонировал в чём-то.
Laminas на этих выходных (31.01.2021) немного копал, первое впечатление — у.г., так что лучше и не смотрите :-) На мой взгляд оверэнжинирнг во всей красе, плюс скудная документация и малое комьюнити. Общее впечатление сугубо отрицательное.
В основном, все более-менее хорошие ваканции крутятся вокруг них.
Это делает его идеальным выбором для крупномасштабных веб-проектов, создаваемых на уровне организаций.
Использую его всегда, даже для своих мелких экспериментов/проектов. Благодаря flex подключаешь только то, что необходимо для проекта.
получающиеся в итоге проекты отличаются высоким уровнем безопасности
их легко поддерживать
Как лихо автор называет черное белым прямо в первых строчках.
А почему 9 примеров? В таких статьях должно быть 10 для красоты!
Не хватает Битрикса ведь по словам его разработчиков он тоже фреймворк :)
- для работы с БД
- для шаблонизации
- для кеширования
- работа с картинками (ресайзы, ватермарки, кропы)
- простейший CRUD чтобы в админке редактировать
- ну и еще контроллер, который можно кастомизировать
Все это влепил в некую систему инициализации, автолоад чтобы нужные классы сразу подгружались и в целом работает, но это все больше как фан-проектик.
В коммерческой разработке всем пофиг обычно на оптимизацию и скорость, там триста раз в день бизнес меняет задания и нужно все это успевать, а еще текучка кадров такая что из 100 человек 30 за год обновляется и может так получиться что в твоей команде из 3х разрабов двое поменялись, поэтому там всеобщая стандартизация, проще сразу нанять человека со знанием определенного фреймворка, чем учить полгода твоему велосипеду.
Что выбрать?
Забыли упомянуть, что далеко не всегда выбирать вообще нужно. Фреймворк — штука громоздкая и часто можно обойтись чистым PHP + компонентами при необходимости.
Тряхнул стариной и леплю свой фреймворк велосипед на базе Swoole и Symfony Components :)
symfony.com/doc/current/create_framework/index.html
по факту как раз рассказывает как слепить свой фреймворк на базе симфонёвых компонент
Slim, Mezzio?
Вместо Swoole или Symfony Components?
Микрофреймворки — Slim, Mezzio
Фреймворки — Symfony, Laravel, Laminas
И все-таки какие критерии?
composer create-project mezzio/mezzio-skeleton mezzio
composer create-project symfony/skeleton symfonyРазмер:
15M ./mezzio
9,1M ./symfonyКоличество файлов в скелете?
cd ./mezzio
git status | grep 'new file' | wc -l
31
cd ./symfony
git status | grep 'new file' | wc -l
19Симфония несомненно прошла большую эволюцию со времен 1/2/3 версии. Меня особенно порадовал приход Flex и ориентация на микроядро.
В этом контексте разница с микрофреймворками существенно сократилась.
Но вместе с тем общая унаследованная идеология все же осталась и не может быть быстро (а возможно и не планируется) изжита.
Задумался над тем как внятно объяснить свои ощущения и опыт — понял что это сложно.
Поэтому собрал вот такой вот наглядный пример, который отчасти демонстрирует разницу для меня.
Вот результат выполнения кода в рамках вами же предложенных скелетов приложений.
По моему опыту в mezzio код имеет тенденцию оставаться линейным по максимуму.
Хотя писать, естественно, можно по-разному.
P.S. Для симфонии пришлось прописать простой индекс-контроллер с банальным эхо.
Запускал все под встроенным в php сервером.
А opencart что не фреймворк
github.com/gotzmann/comet
Внутри доступны все возможности Slim, только быстрее в 10 раз
9 самых популярных PHP-фреймворков