Фреймворк symfony что это
Вступление¶
Вместо использования этих низкоуровневых компонентов, вы можетеиспользовать готовый к использоваию комплексный веб-фреймворк 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: как начать
Проект
Приложения
В отличии от 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. Актуальность. Стоит ли попробовать?
Всем доброго! У нас запускается третий партнёрский курс — Разработчик 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
В компании Outsourcify мы работаем над проектами разного размера: от небольших сайтов, состоящих из нескольких страниц, до сложных бизнес-приложений. В зависимости от конкретного случая мы рекомендуем клиентам разные технические решения (например, мы пишем много одностраничных приложений на JavaScript и работаем с WordPress), но в самых сложных сценариях, когда разрабатываются крупные веб-приложения, занимающие группу разработчиков на несколько недель или месяцев, мы отдаем предпочтение фреймворку Symfony.
История моего знакомства с Symfony
Если говорить откровенно, то я выбрал Symfony прежде всего по личным причинам. Будучи французом, я познакомился с первой версией Symfony еще более 10 лет назад и с тех пор непрерывно использую этот фреймворк, развиваясь вместе с ним. Изначально Symfony был разработан французом Фабьеном Потенсье (Fabien Potencier), а затем поддерживался принадлежащим ему агентством веб-разработки, SensioLabs. Я даже не помню, как именно я узнал о существовании этого фреймворка, но наверняка этому поспособствовало то, что я регулярно посещал франкоязычные веб-сайты. Наличие документации и учебных пособий на французском тоже помогло.
В те годы (2002–2003) я работал ИТ-консультантом и разработчиком в Париже, сотрудничая с крупными корпорациями (EDF, GDF, Alstom). Стандартом для разработки больших бизнес-приложений тогда был язык Java. Я работал над поддержкой и развитием кода существующих приложений, созданных в основном с помощью Spring, Struts и Hibernate.
В свободное время я иногда разрабатывал личные веб-сайты на PHP (например, онлайн-журнал Eklektik Rock, который я несколько раз переделывал). Уже тогда мне этот язык казался удобнее при разработке в простой локальной среде. Я пробовал разные доступные на тот момент фреймворки. Первым из освоенных мной стал Mojavi, я даже смог задействовать его в одном небольшом проекте для клиента.
Когда я решил оставить свою работу в Париже и переехать в Таиланд, я уже открыл для себя первую версию Symfony, которая была выпущена в 2005 году. Перейти от Java-библиотек, которые я использовал на работе, к фреймворку типа MVC, каким являлся Symfony, было довольно просто. Современные PHP-фреймворки очень похожи на Spring MVC, а Propel (библиотека ORM, предлагавшаяся в те времена вместе с Symfony; с тех пор заменена на Doctrine) имела сходства с Hibernate.
Когда я стал фрилансером, мне стало очевидно, что я не буду продолжать программировать на Java: не то чтобы это было невозможно, но простота использования Symfony, возможность его установки на недорогие PHP-серверы, а также тот факт, что у Symfony был открытый исходный код, были явными аргументами в его пользу. Я больше не работал в команде — я работал удаленно на удаленных клиентов. И думаю, что сделал правильный выбор, остановившись на Symfony, — не только в тех проектах, над которыми работал в то время (я начал с приложения для бронирования отелей), но и в долгосрочной перспективе, так как Symfony с тех пор существенно эволюционировал и сегодня, на мой взгляд, является одним из лучших PHP-фреймворков. Не исключаю, что сейчас на нем ведут разработку и в некоторых из тех крупных французских компаний, где я работал 10 лет назад.
Почему из множества популярных PHP-фреймворков стоит выбрать Symfony?
Было бы самонадеянно сказать, что я испробовал абсолютно все остальные PHP-фреймворки, но я действительно испытал многие из них в разные моменты: Zend, CakePHP, CodeIgniter и — совсем недавно — Laravel (главный конкурент Symfony). Это сугубо личное предпочтение, но я всегда возвращался к Symfony. Даже Laravel, который по сути вобрал в себя большинство концепций Symfony и даже позаимствовал из него несколько компонентов (они были напрямую скопированы из Symfony), не показался мне столь же ясным и, главное, надежным, как Symfony. Сегодня, когда я руковожу собственным агентством веб-разработки, состоящим из нескольких команд PHP-разработчиков, этот аспект как никогда важен.
Symfony обладает всеми возможностями, которые можно ожидать от веб-фреймворка, — отличной документацией, экосистемой полнофункциональных плагинов (более 1000 пакетов) и всем тем, что позволяет ускорить создание профессиональных веб-приложений, которые легко поддерживать. По сути это набор полностью бесплатных компонентов с открытым исходным кодом, а его библиотеки предлагают стандартные инструменты, которые можно применять во множестве различных проектов, избегая повторного решения типовых задач. Он соответствует шаблону проектирования Model — View — Controller (MVC), который позволяет разделять задачи и делает работу каждого участника более понятной при сотрудничестве в команде. Этот фреймворк появился в 2005 году как проект с открытым исходным кодом и был первым фреймворком, поддерживающим PHP 5.3. С тех пор фреймворк развивался и теперь поддерживает PHP версии 8, имеет огромное сообщество пользователей и контрибьюторов по всему миру и сегодня является наиболее популярным PHP-фреймворком во многих странах (включая, конечно, Францию, но не Таиланд, где PHP-разработчики отдают предпочтение Laravel).
В нашей компании мы использовали Symfony для разработки различных приложений в таких отраслях, как социальные сети, управление контентом, онлайн-биллинг, маркетплейсы, управление запасами, сервисы для сравнения страховых планов и т. д.
Главные причины выбора Symfony
Гибкая архитектура. Symfony — это хорошо организованный фреймворк, который прост в освоении и использовании. Его архитектура позволяет разработчикам создавать легко поддерживаемые веб-приложения самым простым способом. Symfony включает в себя все, что ожидается от современного фреймворка, и имеет четкую структуру, облегчающую навигацию как в своем коде, так и в коде других разработчиков. Фреймворк полагается на многократно используемые компоненты и подразумевает следование множеству проверенных приемов работы. Кроме того, у него превосходная производительность (хотя и не всегда идеальная).
Инновации. Авторам фреймворка Symfony и сообществу его пользователей свойственно любопытство, которое выходит далеко за рамки мира PHP. Создатели фреймворка внесли вклад в развитие PHP в целом, причем некоторые компоненты Symfony теперь используются в других фреймворках, CMS и известных библиотеках. Многие концепции фреймворка заимствованы из Java (например, внедрение зависимостей), однако Symfony поспособствовал их адаптации к среде PHP. Панель инструментов отладки и панель профилировщика — примеры инструментов, которые помогают программистам продуктивно вести разработку, и без них теперь трудно представить написание кода на PHP.
Совместимость. Symfony позволяет создавать приложения, отвечающие потребностям любого бизнеса, при условии что эти приложения должны работать на веб-платформе. В этом фреймворке учитываются существующие стандарты PHP: PHPUnit, соглашения об именовании классов и т. д. Кроме того, Symfony позволяет использовать некоторые из своих компонентов, не используя при этом весь фреймворк, например систему управления интернационализацией, систему внедрения зависимостей, систему маршрутизации, систему управления формами и многие другие компоненты. Также авторы фреймворка выгодно использовали внешние библиотеки, такие как Doctrine и Swiftmailer, вместо того чтобы заново изобретать то, что уже хорошо работает в других проектах.
Экосистема. Так как фреймворк написан на PHP, для него существует огромное количество полезных сторонних плагинов, называемых в Symfony пакетами (или bundles). Практически всегда можно найти пакет, который поможет в решении той или иной задачи. Фреймворк Symfony также набирает популярность и признание благодаря тому, что его легко установить на любой сервер c Linux (и даже c Windows) и добиться стабильной производительности. Он поддерживает любые базы данных, включая MySQL, PostgreSQL, SQLite и MongoDB. Он поддерживает даже автоматическую валидацию форм и ввода данных пользователем, чтобы избежать SQL-инъекций и XSS-атак.
Репутация. С момента запуска проекта в 2005 году Symfony был быстро принят на вооружение PHP-разработчиками во всем мире. Сегодня он предлагает стабильную среду, которая является популярной и признанной на международном уровне. Количество ссылок на проект значительно возросло с момента его запуска; можно даже сказать, что Symfony внес вклад в «демократизацию» PHP и его распространение в крупных компаниях, хотя в профессиональной среде этот язык еще не так давно ассоциировался с низкой надежностью (и до сих пор ассоциируется, как скажут некоторые, но я не соглашусь). Symfony — это еще и активное сообщество разработчиков и контрибьюторов, которые участвуют в постоянном совершенствовании фреймворка и связанных с ним инструментов.
Стоимость. Будучи ПО с полностью открытым исходным кодом, Symfony автоматически предполагает низкую стоимость использования. Symfony позволяет разрабатывать надежные приложения для любых видов бизнеса в соответствии с потребностями заказчика, предоставляя разработчикам все возможности для управления конфигурацией и индивидуальной настройки этих приложений. Фреймворк содержит набор инструментов, помогающих программистам тестировать и отлаживать приложения, а также документировать процесс разработки в соответствии с корпоративными стандартами. Единственные подразумеваемые затраты — это труд разработчиков и хостинг.
Перевод подготовлен в преддверии старта занятий на курсе «Symfony Framework».
Устройство фреймворка Symfony: от запроса до ответа
Немного истории
Во-первых, все ваши контроллеры обязаны содержать постфикс Controller, что немного неудобно. А во-вторых, ваши контроллеры не принимают зависимости и не могут работать с ними. А что, если вам понадобится какой-то сервис, работающий с API, а тот, в свою очередь, принимает http-клиент Guzzle? Не проблема, делаем так:
Request/Response
index.php 
Request.php
Так в чем разница, если Symfony тоже используют глобальные массивы? Только в ОО-стиле? Не только. Symfony используют этот Request везде в своем коде, не обращаясь к глобальным переменным, что не даст возможности разработчику перебить какие-либо значения, которые Symfony получила в точке инициализации, потому что фреймворк получил значения раньше, чем дело дойдет до исполнения вашего кода. Таким образом, вы можете и дальше продолжать пользоваться глобальными массивами, а можете инжектить в свои экшены класс Request, что намного удобнее и безопаснее:
Также в Symfony есть класс Response, который, как вы могли догадаться, занимается отправкой ответа пользователю, отправкой заголовков и установкой кук.
Response.php
Строгость фреймворка обязывает вас из всех контроллеров возвращать инстанс класса Response. Это может быть не простой Response, а JsonResponse, если вы пишете апи, RedirectResponse, если вам нужно сделать редирект, BinaryFileResponse, если нужно вернуть файл, и многое другое.
А что посередине?
На самом деле, Request/Response – это простые классы, которые могут работать и без Symfony, в них самих ничего необычного нет. Интересно то, что находится между точками запрос и ответ.
В первую очередь, мы создаем экземпляр Kernel’а, передавая туда переменные окружения (в каком окружении находимся – dev или prod – и нужен ли нам дебаг), и вызываем метод handle, куда отправляем текущий Request. Метод handle загружает (boot) бандлы (о них чуть ниже) и инициализирует контейнер (о котором тоже чуть ниже):
Kernel.php
Когда контейнер готов, Symfony достает из него HttpKernel и вызывает у него метод handle, куда передает текущий запрос, тип (MASTER_REQUEST соответствует основному запросу, который пришел от пользователя) и нужно ли ловить ошибку или нет: если нет, Symfony просто выплюнет ошибку вам на экран, если да, то сработают слушатели, подписавшиеся на событие kernel.exception (о слушателях так же ниже), и ответ вернется уже из одного из них.
Контейнер
Теперь настало время поговорить о том, что же такое контейнер и зачем он нужен. Если коротко, то контейнер – это объект, который знает, как создать конкретный класс и как настроить его зависимости. В случае простого MVC, который писал каждый разработчик, вам приходилось или руками инжектить все эти зависимости, или не использовать вовсе, отдавая предпочтение неуправляемым и жестким статическим методам класса. Контейнер же справляется с этой задачей, располагая в результате компиляции всей информацией о всех необходимых сервисах, которые когда-либо может запросить ваше приложение. Таким образом, когда Symfony уже знает, какой контроллер вам нужен, и если этот контроллер требует зависимости, фреймворк использует контейнер для автовайринга (автозагрузки) некоторых сервисов (например, если вы используете Connection, EntityManager или что-то еще). Если вы хотите подробнее почитать про контейнер и внедрение зависимостей, вы можете прочитать статью Мартина Фаулера о принципах внедрения зависимостей, о типах внедрения (через конструктор или сеттер), о контейнерах и многом другом.
Бандлы
Как написано в документации к фреймворку, бандлы – это что-то очень похожее на плагины. У бандлов достаточно широкая конфигурация, их можно включить в любом окружении или отключать вовсе, бандлы могут повлиять на компиляцию контейнера, а также добавляют больше информации о внедряемых сервисах. Объяснять, как писать бандлы, я не буду, эта тема для отдельной статьи.
Посредники
Вероятно, многие слышали про посредники (или middleware): это классы-фильтры, обрабатывающие http-запрос до того, как он попадет в контроллер. Посредники могут не пропустить запрос, если не прошла валидация или аутентификация, и тогда именно посредники возвращают ответ, а не контроллер. Если же все хорошо, один посредник передает запрос другому посреднику, и так по цепочке, пока запрос не попадет в контроллер. А теперь забудьте, что я написал, потому что в Symfony нет посредников, там в качестве оных могут выступать и выступают события. Существует как ряд встроенных событий, которыми обменивается фреймворк в процессе обработки запроса, так и кастомные события, которые вы сделаете сами. Вот список встроенных событий, на которые подписаны слушатели фреймворка и на которые могут подписаться ваши слушатели, чтобы как-то повлиять на работу фреймворка в любой момент:
В аннотациях к константам имен событий указаны сами классы событий, которые может принять ваш слушатель, когда на них подпишется. Например, вот так:
Таким образом, самое первое событие, которое кидает Symfony, – это событие KernelEvents::REQUEST:
HttpKernel.php
HttpKernel.php 
ControllerResolver.php 
ControllerResolver.php
Дальше бросается событие KernelEvents::CONTROLLER :
HttpKernel.php
Сам ArgumentResolver выглядит так:
ArgumentResolver.php
Здесь перебираются все зарегистрированные резолверы, собираются аргументы и возвращаются обратно. Вот для примера два важных резолвера — RequestValueResolver и ServiceValueResolver :
RequestValueResolver.php 
ServiceValueResolver.php
Последний резолвер ( ServiceValueResolver ) как раз и занимается тем, что достает аргументы контроллера из контейнера, если их не получилось достать другими резолверами.
Дальше собирается и вызывается контроллер:
Кроме этого, Symfony бросает оставшиеся 4 события:
Вы можете подписаться на любое из этих событий и по-прежнему повлиять на работу фреймворка. Например, вы можете подписаться на событие EXCEPTION, словить AccessDeniedException, который вы выкинете в любом из контроллеров, и отрендерить шаблон с ошибкой 403:
Или же вы можете переложить всю работу на аннотации, закрыть ею все защищенные маршруты и выкидывать исключение из слушателя, который будет смотреть, определена ли конкретная аннотация над ней или нет. Будет выглядеть это следующим образом:
Сервисы
После этого идем в файл config/services.yaml и начинаем описывать наш сервис. По умолчанию этот файл выглядит следующим образом:
Какая настройка и для чего нужна, я описывать не буду, комментарии напротив каждой из них достаточно подробные.
Предположим, вы написали клиент, который в конструктор принимает токен и GuzzleHttp для запросов к API. Для описания такого сервиса нам нужно определить имя сервиса (в новых версиях фреймворка имена соответствуют FQCN класса), его аргументы и вызываемые методы, если они есть:
В секции arguments список аргументов может быть как упорядоченным, так и параметризированным. Если вы не хотите зависеть от порядка передаваемых аргументов, вы можете их явно привязать к именам аргументов ваших классов. Например:
Давайте усложним задачу. Теперь у вас JWT авторизация, и перед совершением запросов к API необходимо получить access_token, и так постоянно. Однако вы не хотите зависеть от этого фактора в своем коде и не хотите рисковать забыть сделать запрос на получение токена перед запросом. Symfony может вам помочь. Для этого вам необходимо в секции calls перечислить методы, какие нужно вызвать перед тем, как фреймворк отдаст вам сервис:
Теперь при запросе своего клиента вы получите уже полностью сконфигурированный класс.
Вместо завершения
Как видите, Symfony достаточно удобный и легко расширяемый фреймворк. Кроме того, он состоит из компонентов, которые вы можете использовать отдельно от него. Например, самыми популярными из них являются компонент для создания консольных команд, роутинг, dependency injection и некоторые другие.
Если кому-либо понравилось читать про устройство Symfony, дополнительно могу написать про интересные приемы работы с фреймворком и личные (и немного общие) best practice.