php symfony что это
Краткий обзор 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.
Многие современные веб-фреймворки рекламируют себя, как 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
В компании 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 против чистого РНР¶
Почему использовать 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 приложения слегка изменяются, но становятся более гибкими:
Используя правила перенаправления (rewrite) в настройках веб-сервера, index.php в адресе не будет нужен и у вас будут красивые, чистые URLы (например, /show ).
Создание фронт-контроллера¶
Сейчас вы сделаете большой шаг в разработке вашего приложения. Имея единый файл, отвечающий за все запросы, вы можете централизованно управлять такими вещами как безопасность, загрузка конфигурации и маршрутизация. В этом приложении, 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.