Symfony php что это

Вступление¶

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

Почему вы хотите создать ваш собственный фреймворк?¶

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

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

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

Многие современные веб-фреймворки рекламируют себя, как MVC-фреймворки. Этот туториал не будет говорить о MVC-схеме, так как Компоненты Symfony могут создать любой тип фреймворка. В любом случае, если вы посмотрите на семантику MVC, то эта книга о том, как создать часть Контроллера в фреймворке. Для Модели и Просмотра, всё действительно зависит от вашего вкуса и вы можете использовать любые существующие сторонние библиотеки (Doctrine, Propel или старый добрый PDO для Модели; PHP или Twig для Просмотра).

При создании фреймворка, следующая MVC-схема не является правильной целью. Главной целью должно быть Разделение функциональности; Это скорее всего единственная схема дизайна, о которой вам стоит беспокоиться. Фундаментальные принципы Копомнентов Symfony сфокусированы на HTTP-спецификации. Таким образом, фреймворк, который вы будете создавать, должен быть точнее обозначен как HTTP-фреймворк или фреймворк Запроса / Ответа.

До того, как вы начнёте¶

Готовы? Продолжайте читать!

Начальная загрузка¶

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

Чтобы хранить ваш новый фреймворк, создайте каталог где-то в вашем компьютере:

Управление зависимостями¶

Чтобы установить Компоненты Symfony, которые вам нужны для вашего фреймворка, вы будете использовать Composer, менеджер зависимостей проекта для PHP. Если у вас его ещё нет, скачайте и установите Composer сейчас.

Наш проект¶

Вместо создания вашего собственного фреймворка с нуля, мы будем писать одно и то же “приложение” раз за разом, добавляя по одной абстракции за раз. Давайте начнём с наипростейшего веб-приложения, которое можно представить в PHP:

Вы можете использовать встроенный PHP-сервер, чтобы тестировать это великолепное приложение в браузере ( http://localhost:4321/index.php?name=Fabien ):

В других случаях, вы всегда можете использовать собственный сервис (Apache, Nginx, и т.д.).

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.

Источник

Краткий обзор Symfony. Актуальность. Стоит ли попробовать?

Всем доброго! У нас запускается третий партнёрский курс — Разработчик PHP, где мы вместе с Авито подготовили программу, а теперь думаем стоит ли отдельно делать спецкурс по фреймворкам. Первым на рассмотрении оказался Symfony.

Symfony представляет собой один из самых популярных фреймворков для веб-разработки в мире.

Он прошел длинный путь от полностью интегрированного full-stack фреймворка с бэк-офисом в Symfony 1.x к фреймворку, который стал развитием наработок Java-сообщества, и содержавшем в себе компоненты, вдохновленные JEE в версии Symfony2.

Изначально Symfony2 требовал PHP 5.2.7, но PHP 5.3, только вышедший на тот момент, обладал новой объектно-ориентированной моделью, поэтому SensioLabs незамедлительно сделали эту версию обязательной. Уже после в Symfony использовали Composer, завершили документацию и полностью перевели её на английский.

Практически сразу началась миграция крупных open-source проектов на Symfony: OroCRM, EzPublish, Drupal8, PHPBB, PrestaShop, Piwik и многие другие — часть полностью перешла на этот каркас, а некоторые использовали только отдельные программные компоненты. Стоит особо отметить Drupal8 — возможно, это не был самый первый проект, но точно одна из крупнейших CMS на рынке.

Возможность использовать лишь отдельные программные компоненты Symfony позволила обогатить экосистему специализированными программными решениями. Это сместило в тень фреймворк Standard Edition, (так называемое “полное издание” или “мета-пакет”), который уже не мог быть ответом на насущные вопросы бизнеса. Поэтому в 2017 году создатель Symfony объявил, что версия 3.4 для него станет последней.

Неполный список самых известных проектов, использующих Symfony:

Плагин Flex для Composer — это будущая замена Standard Edition. Он позволит сделать разработку Symfony приложений намного легче.

У разработчика появится возможность самому выбирать и добавлять нужные ему зависимости, используя файлы формата YAML. Они объяснят Flex что нужно сделать: добавить зависимость, конфигурировать и зарегистрировать бандл или, например, создать папку.

Найти “рецепты” для Flex можно в официально утвержденном каталоге SensioLabs. Кроме него также существует общественный источник, где каждый может добавить свой рецепт и сделать его доступным для всех.

Для того, чтобы выпустить RESTful API в 2017 году, используя Flex, нужно обратиться к API Platform. Он доступен через Flex, поэтому для получения полностью рабочего приложения достаточно выполнить всего одну команду.

Многие считают, что основной фокус проекта Symfony не на самом фреймворке, а на поддержании высококачественных программных систем и их подробной документации и я не могу с ними не согласится. Думаю, на этот вывод повлиял относительный успех Symfony 3 и популярность таких программных решений, как Akeneo. По-моему, команда Symfony движется в правильном направлении 🙂

Плагин для Composer совместим с Symfony 3.3 и совсем не зависит от выхода Symfony 4, поэтому уже сейчас можно начинать пробовать и эксперементировать.

Если вы хотите быстро разобраться с API Platform, Akeneo, Marello, Sylius, Drupal8, Laravel или фреймворком Symfony Standard Edition, то изучение экосистемы Symfony может вам очень помочь. Стоит обратить внимание на следующие моменты:

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

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

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

Как всегда интересны ваши мнения или тут в комментариях, или на нашем Дне открытых дверей.

Источник

Symfony: как начать

Проект

Приложения

В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.
Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).
Сам я пользуюсь рекомендацией книги и имею два приложения в своем проекте.

Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.

Окружения (environments)

Модули (modules)

… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.

Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.
Последнее, на чем хотелось бы остановиться — это…

Модели (models)

Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно.

Пожалуй, это всё, что может понадобиться новичку при изучении Symfony (чтобы она не казалась ему сложной и непонятной системой, какой она мне показалась год назад).
А вот теперь перейдем непосредственно к моим рекомендациям. Но перед этим я расскажу вам про…

Плагины (plugins)

Мои рекомендации

Ссылки по теме

Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.

Источник

Symfony против чистого РНР¶

Почему использовать Symfony лучше, чем открыть файл, и писать на простом PHP?

Если вы раньше никогда не использовали PHP-фреймворки, не знакомы с философией Model-View-Controller (здесь и далее MVC) или просто интересуетесь шумихой вокруг Symfony, то эта глава создана для вас. Вместо того, чтобы рассказывать вам о том, что Symfony позволяет разрабатывать приложения быстрее и качественнее, чем при использовании чистого PHP, вы убедитесь в этом самим.

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

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

Простой блог на чистом PHP¶

Такой код быстро пишется, так же быстро выполняется, и, по мере роста вашего приложения, становится совершенно неподдерживаемым. Имеется несколько проблем, которые необходимо решить:

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

Изоляция представления¶

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

Изоляция логики приложения (бизнес-логики)¶

На данный момент, приложение содержит только одну страницу. Но что, если при создании второй страницы нужно использовать то же соединение с базой данных, или даже тот же массив постов из блога? Преобразуйте код таким образом, чтобы базовая логика и функции доступа к данным приложения были изолированы в новом файле под названием model.php :

Название файла model.php используется потому, что логика и доступ к данным приложения обычно известен как уровень «модели». В хорошо организованном приложении, большая часть кода, представляющая вашу «бизнес-логику», должна находиться в модели (а не в контроллере). И в отличие от этого примера, только часть модели отвечает за доступ к базе данных (либо не отвечает вовсе).

Контроллер ( index.php ) теперь выглядит очень просто:

Теперь, основной задачей контроллера является получение данных из модели приложения и вызов шаблона для отображения этих данных. Это очень простой пример шаблона model-view-controller.

Изоляция HTML-макета¶

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

Единственная часть кода, которую нельзя использовать повторно – это разметка страницы. Исправьте это путем создания нового файла templates/layout.php :

Шаблон templates/list.php теперь можно упростить для «расширения» файла templates/layout.php :

Добавление страницы блога «один пост»¶

Страница блога “список постов” была оптимизирована для того, чтобы код был более организованным и был пригоден для повторного использования. Для того, чтобы доказать это, добавьте страницу блога “один пост”, которая будет отображать отдельные посты блога по параметру id в запросе.

Далее, создайте новый файл под названием show.php – контроллер для новой страницы:

Наконец, создайте новый файл-шаблон templates/show.php для отображения отдельного поста из блога:

Создать вторую страницу теперь очень просто, и при этом код не дублируется. Тем не менее, эта страница добавляет еще больше проблем, которые вам поможет решить фреймворк. Например, отсутствующий или неверный параметр запроса id приведет к ошибке приложения. Было бы лучше, если бы это вызывало отображение страницы 404, но это пока не так просто сделать.

“Фронт-контроллер” спешит на помощь¶

Решением будет использовать фронт-контроллер – единый РНР-файл, через который будут обрабатываться все запросы. При использовании фронт-контроллера, URI приложения слегка изменяются, но становятся более гибкими:

Создание фронт-контроллера¶

Сейчас вы сделаете большой шаг в разработке вашего приложения. Имея единый файл, отвечающий за все запросы, вы можете централизованно управлять такими вещами как безопасность, загрузка конфигурации и маршрутизация. В этом приложении, index.php теперь должен быть достаточно умным для отображения страницы списка постов блога или страницы отдельного поста, основываясь на URI запроса:

Для улучшения структуры приложения, оба контроллера (ранее /index.php и /index.php/show ) теперь являются функциями РНР, и обе перенесены в отдельный файл под названием controllers.php :

В качестве фронт-контроллера, index.php взял на себя абсолютно новую роль, которая включает в себя загрузку библиотек ядра и маршрутизацию приложения, и заключается в вызове одного из двух контроллеров (функции list_action() и show_action() ). На самом деле, фронт-контроллер начинает выглядеть и вести себя очень схоже с Symfony.

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

На данный момент, приложение разрослось из одного РНР-файла в организованную структуру, которая позволяет повторное использование кода. Скорее всего вы чувствуете себя немного счастливее, но далеко от полного удовлетворения. Например, система маршрутизации ненадежна и не распознает, что страница списка /index.php также должна быть доступна с помощью / (если используются правила вывода Apache). Также, вместо того, чтобы развивать блог, много времени уходит на «архитектуру» кода (например, маршрутизацию, вызов контроллеров, щаблоны, и т.д.). Еще больше времени тратится на отправку форм, проверку введенных данных, запись показаний и безопасность. Зачем вам заново изобретать решения для всех этих рутинных задач?

Добавьте немного Symfony¶

Symfony спешит на помощь. Перед тем, как использовать Symfony, вам необходимо будет ее скачать. Это может быть сделано с использованием Composer, который позаботится о скачивании правильной версии и всех ее зависимостей, предоставляет автозагрузчик. Автозагрузчик – это инструмент, который позволяет начать использовать РНР-классы, не подключая явно файлы, содержащие эти классы.

Создайте в корневом каталоге файл composer.json со следующим содержанием:

Далее, скачайте Composer, и запустите следующую команду, которая скачает Symfony в папку vendor/ :

Объект Response предоставляет гибкость при создании НТТР ответа, и позволяет добавлять НТТР заголовки и контент посредством объектно-ориентированного интерфейса. И хотя ответы в этом приложении достаточно просты, его гибкость окупится по мере развития приложения.

Пробное приложение в Symfony¶

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

Заметьте, что обе функции контроллера теперь находятся в «классе контроллера». Это хороший способ группировать связанные страницы. Функции контроллера также иногда называются действиями (actions).

Файл layout.php практически идентичен:

Когда движок Symfony (который называется Kernel – ядро) загружается, он нуждается в «карте» для того, чтобы знать какой контроллер необходимо использовать, основываясь на информации о запросе. Конфигурация карты маршрутизатора config/routes.yaml предоставляет ему эту информацию в таком формате:

Теперь, когда Symfony занимается всеми повседневными задачами, фронт-контроллер public/index.php становится предельно простым. И поскольку он делает так мало, вам никогда не придется его трогать:

Преимущества Symfony¶

В следующих главах вы узнаете больше о том, как работает каждая составляющая Symfony, и как вы можете организовать свой проект. Сейчас же, ещё раз порадуемся улучшению вашей жизни с переносом блога с чистого РНР на Symfony:

И, возможно, лучшее из всего – используя Symfony, вы теперь имеете доступ к целому ряду высококачественных инструментов с открытым исходным кодом, разработанных участниками Symfony сообщества! Хороший выбор общественных инструментов Symfony можно найти на GitHub.

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.

Источник

Какой PHP-фреймворк выбрать: сравниваем Symfony, Laravel и Yii2

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

Зачем нужен PHP-фреймворк

PHP — один из самых популярных и востребованных языков программирования. Его активно используют крупные проекты, например, Facebook и «ВКонтакте». На PHP написаны популярные системы управления контентом (CMS), в том числе WordPress. На этом движке работает около трети всех сайтов в интернете и около 60 % сайтов на CMS.

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

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

Полезная информация Почему Django — лучший фреймворк для разработки сайтов: статья о характеристиках и особенностях популярного веб-фреймворка.

Как выбрать PHP-фреймворк

Выбрать фреймворк помогут ответы на следующие вопросы:

Symfony, Laravel и Yii2

Перед погружением в детали коротко рассмотрим главные особенности наиболее популярных PHP-фреймворков. Это Symfony, Laravel и Yii2.

Symfony

Symfony представляет собой набор PHP-компонентов, которые подходят для повторного использования. Фреймворк позволяет делать масштабируемые и производительные приложения. API Symfony интегрируется со сторонними приложениями, а также с инструментами для фронтенд-разработки, например, Angular JS.

Symfony используют многие популярные проекты, например, Drupal и phpBB. Даже самый популярный PHP-фреймворк Laravel построен на основе Symfony.

Laravel

По состоянию на середину 2019 года это самый популярный PHP-фреймворк в мире. Текущая стабильная версия — 5.8.10. Популярность Laravel подчёркивает следующий факт: многие хостеры предлагают специальные решения для приложений, созданных с помощью этого фреймворка.

Yii был представлен в 2008 году. Это безопасный, быстрый и производительный фреймворк для разработки веб-приложений. Текущая версия — 2.0.19.

В Yii2 используется пакетный менеджер Composer для управления зависимостями. Благодаря ленивой загрузке Yii2 считается самым быстрым PHP-фреймворком.

Ещё одна особенность Yii2 — интеграция с jQuery. Благодаря этому фронтенд-разработчикам удобно работать с приложениями, созданными на Yii2. Как и в Symfony, в Yii2 используются готовые компоненты. Это ускоряет разработку.

Какой PHP-фреймворк лучше

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

Шаблонизаторы

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

Symfony

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

Laravel

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

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

Изучайте Laravel на Хекслете Курс по Laravel входит в профессию «PHP-программист». Первые курсы в профессии доступны бесплатно после регистрации.

Модульность

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

В Yii2 реализован подход MVC. В этом фреймворке тоже есть компоненты, однако модульность реализована не так хорошо, как в Symphony.

Laravel уступает Symfony и Yii2 в возможности использовать модульный подход для разработки приложений.

Промежуточный вывод: если вам нужен модульный PHP-фреймворк, выбирайте Symfony.

Установка

Каждый фреймворк поддерживает несколько вариантов установки. Например, Symfony, Laravel и Yii2 можно установить с помощью пакетного менеджера Composer. Все фреймворки после установки позволяют работать с шаблонным приложением.

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

Скорость разработки

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

Если вам нужно как можно быстрее создать веб-приложение, и вы никогда не работали с PHP-фреймворками, выбирайте Laravel. Его проще всего изучать, и в сети больше всего руководств именно по Laravel.

Производительность

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

Производительность Laravel — дискутабельный вопрос. По этому критерию он уступает Yii2 и Symfony. Тем не менее в сети можно найти много рекомендаций по ускорению приложений на Laravel.

Поддержка баз данных

По этому критерию бесспорным лидером становится Symfony. Yii2 и Laravel отстают. Конкретную информацию можно увидеть в таблице.

Сообщество и ресурсы

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

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

Если оценивать такой ресурс, как документацию и обучающие материалы, здесь лидером будет Laravel.

Расширяемость

Функциональность фреймворков увеличивается с помощью расширений или пакетов. По этому критерию лидером остаётся Laravel. В каталоге Packalyst можно найти около 9000 пакетов для Laravel.

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

Схожесть характеристик

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

Всё ещё не можете выбрать фреймворк? Вот тезисная информация, которая поможет определиться.

Заключение

Symfony, Laravel и Yii2 можно назвать отличными инструментами для разработки веб-приложений. Автор оригинальной статьи предпочитает Laravel. В то же время он считает Symfony и Yii2 не менее мощными инструментами. Особенностью Symfony можно назвать развитое сообщество, а особенностью Yii — надёжность и безопасность.

Пожалуйста, напишите в комментариях, какой PHP-фреймворк выбираете вы.

Адаптированный перевод статьи Michael J. Garbade How to choose a PHP framework. Мнение автора оригинальной публикации может отличаться от мнения администрации и сотрудников Хекслета.

Источник