symfony что это за программа
Знакомство с Symfony 2
1. Установка и настройка
Скачать дистрибутив можно с официального сайта. Думаю лучше скачать версию-standart которая идёт со всеми дополнительными компонентами. Далее я предпологаю что архив был распакован в корневую папку вашего веб-сервера.
Проверить что все корректно работает можно по этой ссылке: http://localhost/Symfony/web/config.php.
Если все нормально, то можно начинать, но для начала нужно закомментировать одну строку в файле Symfony/web/app_dev.php
Очень странное решение, по умолчанию включать кеш в режиме разработки.
2. Создание нового приложения
Приложения в Symfony 2 имеют модульную структуру, модули называются бандлами (bundle). Наше demo-приложение будет находиться в своём отдельно бандле. В Symfony существует очень много консольных команд, которые помогут вам в работе. Есть соответсвующая команда для генерации структуры нового бандла:
Эту команду нужно выполнить из консоли, находясь в папке Symfony/. Если вы работаете в линуксе, то можете присвоить файлу console права на выполнения и не писать перед ним php. Генератор задаст несколько простых вопросов на каждый из которых у него есть ответ по умолчанию. Так как мы создаём своё первое приложение, то согласимся на все варинты. Итак, нажав несколько раз клавишу enter мы получим скелет нашего бандла в папке Symfony/src/Demos/BlogBundle.
3. Контроллер и основы роутинга
Как и большинство современных фреймворков, Symfony придерживается паттерна MVC. Мы начнём своё знакомство с реализацией этого паттерна в Symfony с последней буквы, т.е. контроллера.
Наш маленький бандл уже имеет один контроллер, он называется DefaultController и находися в папке src/Demos/BlogBundle/Controller. Если вы заглянете внутрь него, то увидите что у него реализован экшен indexAction. Сейчас мы увидим что он делает. Откройте в своём браузере адрес http://localhost/Symfony/web/app_dev.php/hello/username.
Вы можете удивиться почему именно такой адрес у этой страницы, но если внимательно посмотрите на PHPDoc (это такие специальные комментарии, которые начинаются с символов /**) перед функцией indexAction, то наверняка всё поймёте. Аннотация Route указывает по какому адресу доступен данный экшен и какой параметр он имеет.
Вообще, можно добиться того же и без аннотаций, но они применяются в Symfony повсеместно, так что лучше сразу к ним привыкать. С одной стороны они более лаконичны, а с другой для них не очень хорошо поддерживается автокомплит в моей любимой IDE.
За настройку того как будут выглядеть урлы вашего приложения отвечает специальный компонент Routing, он очень гибко позволяет всё настроить. Более подробно можно почитать в соответсвующем разделе документации. Мы же кратко рассмотрим почему наше приложение открывается именно по этому адресу и почему от нас не потребовалось для этого ничего настраивать.
Если вы не очень внимательно читали что у вас спрашивал генератор бандла, то вполне могли пропустить его вопрос о том обновить ли настройки роутинга в соответствии с новым бандлом. Если пропустили, то можете открыть файл Symfony\app\config\routing.yml. Там вы увидите такую запись:
DemosBlogBundle:
resource: «@DemosBlogBundle/Controller/»
type: annotation
prefix: /
Первая строка — это название секции с конфигурацией, оно соответсвует имени нашего бандла. Вторая строка — указывает откуда импортировать настройки. В данном случае будут читать все файлы из папки с контроллерами, а следующая строка говорит что все необходимые настройки описаны в аннотациях экшенов. Ну а аннотации мы уже видели. И, наконец, последняя строка указывает какой префикс будет добавлен ко всем урлам из нашего бандла. По умолчанию все урлы доступны напрямую от имени входного скрипта. Давайте поменяем / на /blog чтобы было более логично.
Теперь все что мы будем делать будет доступно по адресу http://localhost/Symfony/web/app_dev.php/blog.
4. Работа с Doctrine: создание модели
Теперь перейдем к следующему шагу — работе с базой данных. Я буду использовать Doctrine, хотя никто не обязывает этого делать, вместо доктрины можете использовать любой удобный вам способ работы с бд. Однако, доктрина хорошо интегрирована с symfony и работать с ней одно удовольствие.
Для начала настроим подключеник к бд. Откройте файл app/config/parameters.ini и опишите свои настройки. Кстати, интересно, почему все настройки по дефолту в yml, а этот в ini-файле. Если в настройках вы указали не сущесвующую базу данных, то выполните следующую команду:
php app/console doctrine:database:create
и доктрина сама создаст её.
Доктрина является полноценной ORM, но построна она по другому принципу нежели ActiveRecord, с которым у многих сейчас однозначно ассоциируется это понятие. Доктрина реализует шаблон Data Mapper который очень подрбно описан здесь.
Для начала нам нужно описать сущность с которой мы будем работать. Это будет класс Post с нужными нам свойствами. Создайте папку src/Demos/BlogBundle/Entity. В ней создайте файл Post.php и заполните его следующеим кодом:
Сам класс никак не связан с базой данных, но в аннотациях содержится описание какие из свойств класса будут колонками таблицы и какого типа они будут. Думаю из аннотаций всё вполне очевидно. Все свойства объявлены защищёнными, поэтому для доступа к ним нужно создать геттеры и сеттеры. Для это используем соответсвующую команду доктрины:
php app/console doctrine:generate:entities Demos/BlogBundle/Entity/Post
Теперь посмотрите в файл Post.php, в нём должны были появиться соответсвующие методы. У нас есть есть описание модели, по ней нужно создать соотвествующую таблицу в базе данных. Для этого выполните:
Если все прошло без ошибок, то в вашей бд должна было появиться таблица post. Перейдём к непосредсвенной работе с объектами. В классе DefaultController создайте новый экшен с таким кодом:
/**
* @Route(«/create»)
*/
public function createAction() <
$post = new Post();
$post->setTitle(‘Demo Blog’);
$post->setBody(‘Hello Symfony 2’);
$post->setCreatedDate(new \DateTime(«now»));
$post->setUpdatedDate(new \DateTime(‘now’));
А в начало файла нужно добавить импорт нужных пространств имён:
use Demos\BlogBundle\Entity\Post;
use Symfony\Component\HttpFoundation\Response;
Теперь если вы откроете адрес http://localhost/Symfony/web/app_dev.php/blog/create, то в ответ должны получить id созданной записи.
Теперь создадим экшен для вывода сущесвующих записей. Для этого нам понадобится экшен с параметром, который будет принимать id записи.
Теперь можете просмотреть запись пройдя по ссылке http://localhost/Symfony/web/app_dev.php/blog/show/1. На этом с доктриной закончим, подробности в документации.
5. Twig: первые шаблоны
Пора перейти к заключительной части нашего знакомства с Symfony. На прошлом шаге мы поступили не очень хорошо смешав логику работы с выводом записи в showAction. Избавиться от этого недостатка нам поможет View (по русски «вид» звучит как-то не очень хорошо, поэтому я буду называть это вьюхой ;).
В качестве шаблонизатора Symfony использует Twig — пожалуй лучший PHP-шаблонизатор с которым я работал. Как и любой другой компонент симфони можете заменить его на то, что вам больше нравится.
Как вы помните у экшена indexAction есть специальная аннотация Template(), которая говорит что у него есть шаблон.
Массив который возвращается из экшена передаётся во вьюху, ключи массива буду именами переменных которые будут там доступны.
Давайте изменим экшен show. Нужно добавить соответсвующую аннотацию и вместо того чтобы возвращать объект Response вернуть массив в котором будет просматриваемая запись. Вот что получилось:
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 «из коробки» обеспечивает защиту от большинства угроз, актуальных для веба на сегодняшний день. В данной статье я сделаю обзор основных механизмов, делающих разработку на Symfony безопасной.
Автор: Удальцов Валентин,
студент кафедры информационной безопасности
“Высшей школы экономики”
Введение
Среди задач, решаемых современными PHP бэкэнд-фреймворками можно выделить три основные:
Symfony – второй по популярности PHP-фреймворк. Он построен вокруг архитектурной парадигмы Model-View-Controller, использует шаблонизатор Twig, Doctrine Object Relation Mapper, предоставляет мощный Dependency Injection Container, включает в себя парсер конфигурации из форматов XML и YAML, конструктор легко валидируемых форм, инструменты для тестирования, кеширования, работы с мультиязычностью, а также продуманную Security-компоненту для работы с аутентификацией и авторизацией пользователей.
Стандартная, рекомендуемая к установке сборка Symfony «из коробки» обеспечивает защиту от большинства угроз, актуальных для веба на сегодняшний день. В данной статье я сделаю обзор основных механизмов, делающих разработку на Symfony безопасной.
Защита от XSS-атак
Вывод в шаблоне введенных пользователем данных без правильного экранирования порождает угрозу XSS-атаки. У злоумышленника появляется возможность эксплуатировать вредоносный код на стороне других клиентов.
Небезопасный код
Базовое решение
Второй подход существенно сократит код, сделает его более наглядным, но не решит фундаментальной проблемы. Разработчик по-прежнему может забыть написать небезопасный код. Базовое решение проблемы безопасности связано с достаточно большими издержками.
Решение в Symfony
Symfony использует шаблонизатор Twig. Помимо того, что Twig предоставляет огромное количества удобных инструментов для организации шаблонов, он задает определенные правила вывода переменных. В частности, при стандартных настройках Twig по умолчанию экранирует спецсимволы:
Защита от SQL-инъекций
SQL-инъекции возможны при отсутствии экранирования переменных при подстановке данных в код запроса.
Небезопасный код
Базовое решение
Помимо того, что базовое решение опять сопряжено с высокими издержками на написание дополнительного кода, оно оставляет разработчику большой простор для ошибки при формировании самой фразы запроса. В определенных ситуациях неправильно организованный код может породить валидные, но нежелательные запросы, которые нарушат целостность или доступность информации.
Symfony
Для работы с базой данных Symfony использует сторонний проект Doctrine.
Главная компонента, Doctrine DBAL (Database Abstraction Layer), дает возможность быстро и удобно подставлять экранированные данные в тело запроса.
При помощи этой библиотеки можно также конструировать запрос, используя ООП:
Такой подход исключает появление в запросе неожиданных конструкций. В случае нарушения каких-либо структурных правил построения запроса библиотека выдает ошибку на уровне PHP, а не на уровне синтаксического анализатора SQL. Это изолирует данные от ошибочных запросов.
В стандартную сборку Symfony также интегрирована библиотека Doctrine ORM, которая позволяет работать не с самим SQL-запросом или его конструктором, а непосредственно с PHP-объектами. Классы моделей размечаются определенным образом (например, при помощи аннотаций в phpDoc), в результате чего свойства объектов проецируются на колонки таблиц в бд. Взаимодействие между объектом и строкой в бд (создание, редактирование, удаление) происходит автоматически через отлаженные механизмы, что помимо повышения скорости разработки сводит к минимуму возможность ошибки.
Валидация входящих данных
Неотъемлемой частью веб-приложения являются формы. PHP является слабо типизированным языком, поэтому серверная валидация и приведение входящих данных к типам является особо острым вопросом.
Базовое решение
Подход к валидации форм в Symfony
Валидация в Symfony глубоко интегрирована в сам механизм конструирования форм. Например, при объявлении поля типа выпадающий список (или группы радиокнопок) обязательным является указание списка опций. Получив заполненную форму, фреймворк автоматически проверяет данные на соответствие предлагавшимся опциям.
Кроме того, Symfony позволяет размечать модели (свойства которых населяются входящими данными после обработки запроса) различными валидаторами, а затем за пару строк кода получать массив ошибок.
Security Component: аутентификация и авторизация средствами Symfony
Symfony делает акцент на разделении двух ключевых в безопасности понятий – аутентификации и авторизации. Напомню, в чем их принципиальное различие.
Аутентификация
Аутентификация – процедура проверки подлинности. Её главная и, по сути, единственная задача состоит в том, чтобы идентифицировать пользователя.
Веб приложение является запросно-ответной системой. В связи с этим в контексте веб-приложения под идентификацией можно понимать установление однозначной связи между текущим запросом и неким объектом пользователя (например, строкой в базе данных в таблице user ).
Визуально аутентификация происходит только на странице ввода логина и пароля. Однако по факту, в той части веб-приложения, которая в принципе предусматривает аутентификацию, она происходит при каждом запросе к серверу. Связано это опять-таки с запросно-ответным принципом работы протокола HTTP. При базовом сценарии после отправки ответа аутентифицированному пользователю соединение разрывается и нет никакого иного способа идентифицировать автора следующего запроса, кроме как аутентифицировать его снова. Разница в том, что после первой успешной парольной аутентификации последующие процедуры (при соблюдении определенных условий) используют другие механизмы, не требующие ввода пароля (например, проверку токена в Cookie).
Аутентификация в Symfony
Авторизация
После опознания клиента система должна определить, имеет ли пользователь право получить ответ по сформированному им запросу или нет. Механизм авторизации предусматривает наличие матрицы отображения из множества пользователей в множество ресурсов. Соответственно, имея идентификатор ресурса (полученный после обработки запроса), идентификатор пользователя (полученный в результате аутентификации) и матрицу соответствий, система отвечает на вопрос: «Имеет ли данный пользователь доступ к данному ресурсу?».
Авторизация в Symfony
Symfony использует мандатный принцип контроля доступа. Каждый пользователь имеет своё место в иерархии ролей; для каждого ресурса можно указать, какие роли имеют к нему доступ.
Соответственно, процесс авторизации в Symfony делится на следующие подпроцессы:
Безусловно, Symfony позволяет модифицировать и расширять оба механизма в разных его частях. Например, можно организовать несколько независимых или связанных защищенных зон, реализовать неограниченное количество провайдеров пользователей (имплементировав соответствующие интерфейсы), использовать различные способы аутентификации.
Отдельное внимание в Symfony уделяется криптографии. Через конфигурацию для класса пользователя можно определить любой тип шифрования пароля:
Заключение
Я рассмотрел основные инструменты фреймворка Symfony, позволяющие решить главные вопросы безопасности веб-приложения. Стандартная сборка Symfony предусматривает защиту от XSS- и CSRF-атак, SQL-инъекций, включает инструменты быстрой и понятной валидации форм, механизмы аутентификации и авторизации.
Важно понимать, что помимо реализации самих механизмов, немалое значение имеет общая архитектура фреймворка, которая обязывает разработчика следовать определенным канонам проектирования.
Рекомендации
Несмотря на большое количество достойных внимания PHP-фреймворков, я знаю людей, которые до сих пор «изобретают свои велосипеды». К сожалению, работая над большими проектами с запутанной бизнес-логикой, невозможно успешно балансировать между написанием инструментов разработки и имплементацией этой логики.
На мой взгляд, гораздо правильнее изучить какой-нибудь достаточно популярный веб-фреймворк (Symfony, Yii, Laravel, Zend и т.д.) и сосредоточиться на самом проекте. Это позволит одни махом решить большую часть потенциальных проблем с безопасностью и существенно сузить круг возможных ошибок.
Что такое Symfony?
Давайте в общих чертах познакомимся с таким понятием как «Symfony» в веб-разработке. Что это такое и зачем это нужно?
Официальный сайт этого фреймворка:
Используя Symfony можно значительно проще работать с веб-формами, просто и быстро работать с базой данных, с email почтой, с помощью специальных функций формировать внешний вид документа, который будет представлен пользователю и многие другие возможности.
Главная идея фреймворка Symfony в том, что этот фреймворк имеет модульную структуру. Symfony работает в связке с менеджером проектом Composer и позволяет собирать проект буквально по кубикам, по кусочкам.
Если вам нужен модуль для работы с почтой, вы его устанавливаете, если он вам не нужен, вы его не устанавливаете. Если нужен модуль для работы с базой данных, вы его устанавливаете и.т.д.
Вы сами можете выбирать, какие модули вам нужны и это экономит дисковое пространство для создания веб-приложений и ваш сайт будет загружаться быстрее т.к. ядру системы нужно будет обрабатывать намного меньше информации.
Также фреймворк Symfony работает на шаблоне проектирования (программирования) MVC.
Symfony работает на принципах ООП.
Подробнее об этой модели программирования поговорим позже. Сейчас важно знать, что все самые передовые технологии программирования фреймворк Symfony, как правило, поддерживает и создавать сложные веб-проекты с его помощью намного быстрее и проще.
Такие основные преимущества фреймворка Symfony. Надеюсь, что стало понятнее что это такое и для чего это нужно.
Если вам стало интересно познакомиться с этим ближе, приступайте к изучению следующих уроков.
Это позволит экономить часы свободного времени и решать многие задачи программирования легко и просто.
Давайте будем постепенно осваивать эту тему и я постараюсь Вам в этом помочь. Для начала, давайте немного познакомимся и определимся с основными задачами.
Напишите в комментариях:
1) Для решения каких задач вы планируете использовать фреймворк Symfony в своей работе?
2) Если изучали работу с Symfony раньше, с какими трудностями сталкивались? Что мешало освоить этот фреймворк полноценно?
3) Есть какие-нибудь ожидания от этого курса? Что бы хотелось в нем увидеть?
Что мы знаем о Symfony: мифы и легенды
Авторизуйтесь
Что мы знаем о Symfony: мифы и легенды
Когда веб-разработчика спрашивают о Symfony, у него в голове, как правило, рисуется определенная картина, некое устоявшееся мнение. Что можно сказать о Symfony в одном предложении? Это full-stack веб-фреймворк, написанный на PHP. Всё так, но это не совсем точное определение. Понятие Symfony несколько шире стандартного понимания.
Symfony — это набор автономных компонентов. В свою очередь компоненты, связываясь между собой, образуют веб-платформу, своеобразную экосистему. При этом то, какие компоненты выбирать, зависит от вас и ваших задач. Вы также можете воспользоваться минимальным набором для создания простого приложения или прототипа или же развернуть тот самый полнофункциональный фреймворк Symfony.
Ребята из Noveo пообщались со своими PHP-разработчиками и выделили общие ключевые моменты, которые были отмечены, и задались вопросом, действительно ли всё так хорошо / плохо, как говорят. Так получилась эта подборка мифов и легенд о Symfony.
Низкая связность компонентов
Модульность — одна из наиболее важных особенностей работы с Symfony. Как уже было отмечено выше, Symfony являет собой набор переиспользуемых и автономных компонентов — бандлов. В Symfony всё есть бандл, и всё живёт в бандлах — и компоненты ядра фреймворка, и код вашего приложения. Такое архитектурное решение предоставляет возможность строить приложение очень гибко. Шаг за шагом вы строите свою структуру — по кирпичику, таким образом ваше приложение уже не монолитная стена, и, чтобы заменить какой-то модуль, вам не нужно рушить всё приложение. Причём конечную конфигурацию, разумеется, можно настроить «под себя». Более того, вы можете использовать отдельные компоненты Symfony вне фреймворка. Данным подходом успешно пользуются и другие проекты, например, Laravel, Drupal, Magento и многие другие.
Отдельно следует отметить поддержку Dependency Injection в Symfony как одну из главных фич фреймворка. Использование DI снижает связность и упрощает тестируемость кода.
В Symfony много готовых решений
Это действительно так — решения есть для самых разнообразных задач, от повседневных до экзотических. На сегодняшний день существует более 2500 бандлов, каждый из которых вы можете подключить и использовать — спасибо модульности. Если по каким-то причинам один из бандлов не подходит, его можно заменить на аналогичный, благо выбрать есть из чего. Или же, одновременно исправив фатальный недостаток и исполнив заветную мечту программиста, написать свой — такой же, но другой. Пожалуй, здорово иметь возможность переиспользования готовых компонентов и сторонних библиотек и в то же время не быть прибитым гвоздями к конкретной технологии или инструменту.
Symfony сложный
Symfony слишком сложный. Отчасти это так — у Symfony более высокий порог вхождения по сравнению с другими PHP-фреймворками. Соответственно, и времени на его освоение требуется гораздо больше. Новичкам придется непросто. Здесь и использование инновационных возможностей языка, и применение паттернов проектирования. Нужно быть готовым к тому, что изучением только Symfony дело не ограничится. В придачу следует ознакомиться с технологиями и инструментами, которые идут рука об руку с Symfony и позволят использовать его максимально продуктивно: Twig, SwiftMailer, Monolog, phpUnit, Doctrine, а также наиболее популярные бандлы, например, FOS, Knp, Gedmo и др.
Symfony спроектирован очень грамотно
Symfony отличается выстроенной концепцией и идеологией, но важно понимать, что он не даёт готового и единственно правильного решения при разработке проекта. Задача построения конечной архитектуры приложения (не забываем уважать стандарты) целиком и полностью делегируется разработчику и остается на его совести. Отсюда можно выделить два следствия, которые перекликаются с предыдущим пунктом: опытный Symfony-разработчик с большей степенью вероятности обладает глубокими знаниями языка в частности и навыками проектирования в целом. Второй, не столь жизнерадостный момент: найти грамотных Symfony-разработчиков сложнее, а воспитание собственных требует времени.
Symfony делает вас свободными
Считаете, что подключили бандлы и можно работать? Секундочку, не всё так просто. Поскольку фреймворк гибкий, то и возможностей для его настройки много. Конфиги и аннотации — наше всё. В стандартной поставке фреймворка базовые конфигурационные файлы уже присутствуют. Однако разработчики Symfony не ограничиваются yaml-файлами. Для конфигурирования приложения или отдельных его частей предоставлена возможность использовать аннотации, конфиги в виде xml- или php-файлов. Единого стиля нет, и каждый использует тот способ, который представляется наиболее удобным. Конечно, по многим моментам есть рекомендации, что использовать в той или иной ситуации, но это не накладывает на разработчиков дополнительных ограничений, они вправе самостоятельно делать выбор.
Что это — свобода или хаос? Данную ситуацию можно развернуть в любую сторону. Всё достаточно просто. Предоставляя людям выбор, вы возлагаете на них ответственность. Очевидно, что при безалаберном использовании приложение легко превратится в лоскутное одеяло, а качество продукта не будет высоким. Правильным решением будет ещё до начала активной стадии разработки договориться внутри команды о подходе к конфигурированию приложения и описанию кода. Общение — ключ к успеху.
Symfony подходит только для крупных проектов
Сложный вопрос. Symfony, если мы говорим о full-stack фреймворке, хорош для относительно крупных проектов. Пожалуй, следует согласиться с тем, что Symfony — не всегда лучший выбор для небольших проектов за несколькими исключениями. Первое — он может быть использован, если требуется решать сравнительно типовые задачи, а выигрыш за счёт быстрого старта и использования стандартных бандлов значителен. Однако в данном случае к выбору следует подходить осознанно, взвесив все преимущества и проблемы, с которыми, возможно, придётся столкнуться. Использование Symfony для мелкого API (можно посмотреть в сторону микро-фреймворков, например, тот же Silex) или простенького сайта можно сравнить с поездкой за продуктами на фуре-длинномере — да, едет, но медленнее и дороже в сравнении с легковыми. Второе исключение — использование Symfony «на вырост» в перспективе расширения проекта и его масштабируемости. В любом случае, инструмент следует выбирать исходя из задач, а не наоборот.
Symfony медленный
Я бы не назвал Symfony медленным. В рамках этой статьи мы не будем производить замеры производительности, у нас нет такой задачи, но думаю, не составит большого труда найти самые разнообразные бенчмарки php-фреймворков. Глядя на их результаты, становится ясно, что быстродействие Symfony на достойном уровне, хотя он и не является фаворитом в плане производительности, существуют более быстрые фреймворки. Важно понимать, почему так происходит. Все плюшки, которые мы получаем от работы с Symfony, требуют ресурсов, да и абстракция не бесплатна. За всё нужно платить, и в программировании за удобство, качество и скорость разработки зачастую приходится платить производительностью.
Здесь сразу возникает холиварный вопрос: что имеет бОльшую цену — стоимость разработки или стоимость хостинга? На мой взгляд, легче добавить сервер, тем самым повысив производительность приложения, чем найти и добавить нового разработчика на проект. Разумеется, это абсолютно не означает, что не нужно задумываться об оптимизации продукта и конечном быстродействии. Нужно, и очень важно всегда принимать во внимание данный аспект. Не открою Америки, если скажу, что оптимизация производительности не является лёгкой задачей. Для её решения следует понимать, что происходит внутри, и в деталях представлять, что может привести к замедлению и каким образом справляться с нагрузками.
Слишком много магии
Мощное сообщество
Пожалуй, этот аргумент можно услышать в разговоре о практически любом более-менее популярном фреймворке или языке программирования. Каждый убеждён, что сообщество масштабное, крайне дружелюбное, отзывчивое и готово причинять добро каждому новичку. Как бы это ни звучало банально, но сообщество Symfony на самом деле масштабное. Большое количество разработчиков на github и stackoverflow, которые отвечают на вопросы (в том числе core-разработчики и разработчики бандлов). При этом общение не является односторонним, любой желающий может создавать pull-request’ы, вносить предложения, создавать свои бандлы. Любителям живого общения следует отметить, что сообществом регулярно проводятся конференции как международные, так и национальные.
Поддержка и финансирование
Еще один важный момент для open-source проекта, который не всегда выделяют — поддержка коммерческой компании, в данном случае — SensioLabs. Компания предлагает дополнительные услуги, такие как консалтинг, обучение, различные сертификации. Это придает дополнительную уверенность в плане стабильности проекта, в дальнейшем росте и развитии экосистемы фреймворка.
Хорошая документация
Нельзя не отметить высокий уровень документации, она актуальна для каждой версии фреймворка, описывает не только компоненты, но и наиболее популярные бандлы. До недавнего времени на официальном сайте можно было найти книгу по практическому применению Symfony, список рецептов и лучшие практики по использованию фреймворка. К 5-летию второй версии фреймворка создатели решили основательно переработать документацию, создав два раздела: Getting started — короткая книга по основам работы с фреймворком и Guides — руководства по отдельным темам. К сожалению, все обозначенные выше материалы не доступны на русском языке, и этот факт можно отметить как дополнительный барьерчик для новичков, но не стоит пугаться — документация довольно хорошо структурирована, написана понятным и простым языком, содержит примеры кода и в ней достаточно легко разобраться.
Symfony не ограничивает вас в выборе, он предоставляет свободу действий, но в то же время требует детального понимания принципов работы и возлагает ответственность за построение структуры приложения.
Вся суть аннотаций Symfony в одном контроллере: