Платформа Symfony в настоящее время является одной из самых популярных платформ PHP, существующих в среде разработчиков PHP. Версия 2, выпущенная несколько лет назад, значительно улучшилась и, на наш взгляд, стала одним из ключевых элементов для того, чтобы сделать экосистему PHP пригодной для крупных корпоративных проектов. Версия 2.0 платформы не только требовала современной версии PHP (минимальная версия, требуемая для Symfony – PHP 5.3.8), но также использует современную технологию – пространства имен и анонимные функции. Авторы также приложили немало усилий, чтобы обеспечить долгосрочную поддержку и минимизировать изменения, которые нарушают совместимость версий. Кроме того, Symfony заставил разработчиков использовать несколько полезных концепций дизайна. Ключевым концептом, представленным в Symfony, был DependencyInjection.
Ключевые причины использования Symfony
Symfony2 признан в экосистеме PHP, как очень хорошо написанный и хорошо поддерживаемый фреймворк. Шаблоны проектирования, рекомендованные и принудительные в рамках среды, позволяют работать в группе более эффективно, что позволяет проводить более качественные тесты и создавать повторно используемый код.
Знания Symfony также можно проверить с помощью системы сертификатов, что позволяет легко находить своих разработчиков и быть более узнаваемыми на рынке. Наконец, что не менее важно, компоненты Symfony2 используются как части других проектов, например:
- Drupal;
- phpBB;
- Laravel;
- eZ Publish и тд.
Со временем есть большая вероятность того, что вы найдете части компонентов Symfony2 в других решениях с открытым исходным кодом. Пакеты и расширяемая архитектура также являются одними из ключевых плюсов Symfony.
Они не только позволяют упростить вашу работу за счет простой разработки многократно используемого кода, но также позволяют находить меньшие или большие фрагменты кода, которые вы можете встроить и использовать в своем проекте, чтобы ускорить работу.
Стандарты Symfony также облегчают отлов ошибок и написание качественного кода, а его сообщество растет с каждым годом.
Структура каталогов Symfony
Давайте углубимся в начальную структуру каталогов в типичном приложении Symfony. В нем вы найдете: app, bin, src, vendor, web.
Хотя Symfony очень гибок с точки зрения структуры каталогов, рекомендуется сохранить базовую структуру, упомянутую ранее.
Следующий список описывает их назначение:
- app – содержит информацию об общей конфигурации, маршрутизации, конфигурации безопасности, параметрах базы данных и многого другого. Это также рекомендуемое место для размещения новых файлов просмотра. Этот каталог является отправной точкой;
- bin – содержит некоторые вспомогательные исполняемые файлы. Он не очень важен в процессе разработки и редко изменяется;
- src – данный каталог содержит код проекта PHP (обычно ваши пакеты);
- vendor – это сторонние библиотеки, используемые в проекте. Обычно этот каталог содержит все сторонние пакеты, библиотеки и другие ресурсы с открытым исходным кодом. Стоит отметить, что рекомендуется хранить файлы в этом каталоге вне системы контроля версий. Это означает, что вы не должны изменять их ни при каких обстоятельствах. К счастью, есть способы изменить код, если он больше соответствует вашим потребностям. Это будет продемонстрировано, когда мы реализуем управление пользователями в нашем приложении;
- web – этот каталог доступен через веб-сервер. Он содержит основную точку входа в приложение (обычно это файлы app.php и app_dev.php), файлы CSS, файлы JavaScript и все файлы, которые должны быть доступны через веб-сервер (загружаемые пользователем файлы).
Таким образом, в большинстве случаев вы обычно будете модифицировать и создавать файлы PHP в каталоге src/, файлы представления и конфигурации в каталоге app/ и файлы JS/CSS в каталоге web/.
Основной каталог также содержит несколько следующих файлов:
- .gitignore;
- README.md;
- composer.json;
- composer.lock.
Цель файла .gitignore состоит в том, чтобы предоставить некоторые предварительно сконфигурированные настройки для репозитория Git, в то время как файлы composer.json и composer.lock – это файлы, используемые менеджером зависимостей composer.
Что такое бандл?
В приложении Symfony вы будете часто использовать термин «bundle» (пакет, набор). Bundle – это что-то вроде плагинов. Таким образом, он может содержать любые контроллеры кода, представления, модели и сервисы. Пакет может интегрировать сторонние библиотеки, а также содержать некоторый код JavaScript/CSS. Мы можем сказать, что почти все является пакетом в Symfony; даже некоторые из базовых функций фреймворка вместе образуют бандл. Пакет обычно реализует одну функцию или функциональность. Код, который вы пишете, во время создания приложения Symphony, также является пакетом.
Есть два типа пакетов. Первый тип пакета – это тот, который вы пишете в приложении, который зависит от проекта и не может использоваться повторно. Для этого существует специальный пакет AppBundle, созданный для вас при установке проекта Symfony.
Кроме того, существуют пакеты многократного использования, которые совместно используются различными проектами, написанными вами, вашей командой или предоставленными сторонними поставщиками. Ваши собственные пакеты обычно хранятся в каталоге src/, а сторонние пакеты находятся в каталоге vendor/.
Каталог vendor используется для хранения сторонних библиотек и управляется композитором. Как таковой, он никогда не должен изменяться вами.
Существует множество повторно используемых пакетов с открытым исходным кодом, которые помогут вам реализовать различные функции в приложении. Многие из них помогут вам в управлении пользователями, написании API-интерфейсов RESTful, создании более качественной документации, подключении к Facebook и AWS и даже создании целой панели администратора. Существует большое количество пакетов, и каждый день появляются новые.
Название пакета связано с ключевым словом PHP. Поэтому оно должно следовать некоторым техническим правилам и заканчиваться суффиксом Bundle. Вот несколько примеров правильных имен: AppBundle и AcmeDemoBundle, CompanyBlogBundle или CompanySocialForumBundle и т. д.
Composer
Symfony построен на основе компонентов, и было бы очень трудно управлять зависимостями между ними и средой без менеджера зависимостей. Чтобы упростить установку и управление этими компонентами, Symfony2 использует менеджер под названием composer.
Вы можете получить его на сайте https://getcomposer.org/. Composer позволяет легко устанавливать и проверять все зависимости, загружать их и интегрировать в вашу работу. Если вы хотите найти дополнительные пакеты, которые можно установить вместе с компоновщиком, вам следует посетить https://packagist.org/. Этот сайт является основным хранилищем Composer и содержит информацию о большинстве пакетов, которые можно установить вместе с ним.
Чтобы установить composer, перейдите по адресу https://getcomposer.org/download/ и ознакомьтесь с инструкцией по загрузке. Инструкция по загрузке должна быть похожа на следующую:
Если загрузка прошла успешно, вы должны увидеть файл composer.phar в вашем каталоге. Переместите его в каталог проект, там же где у вас лежат файлы composer.json и composer.lock. При желании вы также можете установить его глобально, с помощью этих двух команд:
Файлы конфигурации
Каждое приложение должно содержать некоторые глобальные и машинно-специфические параметры и конфигурации. Symfony хранит конфигурацию в каталоге app/config, которая разбита на несколько файлов следующим образом:
- config.yml;
- config_dev.yml;
- config_prod.yml;
- config_test.yml;
- parameters.yml;
- parameters.yml.dist;
- routing.yml;
- routing_dev.yml;
- security.yml;
- services.yml.
Все файлы, кроме файлов parameters.yml*, содержат глобальную конфигурацию, в то время как файл parameters.yml содержит информацию, относящуюся к компьютеру, такую как хост базы данных, имя базы данных, пользователь, пароль и конфигурация SMTP.
Дефолтный файл конфигурации, сгенерированный новой командой Symfony, создается автоматически при установке Composer:
Как видите, он в основном содержит параметры, относящиеся к базе данных, SMTP, настройкам локали и секретному ключу, которые используются внутри Symfony. Здесь вы можете добавить свои пользовательские параметры, используя тот же синтаксис. Рекомендуется хранить в этом файле только данные, относящиеся к компьютеру, такие как пароли, токены, API-ключи и ключи доступа. Размещение паролей в общем файле config.yml считается ошибкой безопасности.
Глобальный файл конфигурации (config.yml) разделен на несколько других файлов, называемых routing*.yml, которые содержат информацию о маршрутизации в рабочей конфигурации. Файл, называемый security.yml, содержит информацию, связанную с аутентификацией и защитой доступа к приложению. Обратите внимание, что некоторые файлы содержат информацию для разработки, производства или тестирования. Вы можете определить свой режим при запуске Symfony через консоль командной строки и при запуске через веб-сервер. В большинстве случаев при разработке вы будете использовать dev mode.
Формат конфигурации
Symfony может обрабатывать конфигурацию в разных форматах: YAML, XML и аннотации. Основные конфигурационные файлы в app/config предоставляются в формате YAML. XML обычно труднее читать, поэтому используется только со сторонними пакетами.
Хотя конфигурация YAML и XML довольно проста и не требует пояснений, нам следует ненадолго остановиться на аннотациях. В качестве примера взгляните на класс AppBundle/Controller/DefaultController:
Если вы знакомы с соглашением PHPDoc или JavaDoc, вы узнаете @token в предыдущем примере. Однако вы можете заметить одну маленькую деталь – это не стандартный токен. На самом деле это не просто комментарий. В нашем примере аннотация маршрута (импортируемая здесь через ключевое слово use) настраивает маршрутизацию с именем домашней страницы и /URL.
Аннотации, как правило, просты в обращении и являются наиболее удобным способом настройки различных аспектов вашего приложения, но в то же время они являются наиболее противоречивыми.