В ноябре этого года планируется релиз фреймворка — Symfony 4. Предлагаю вашему вниманию обзор некоторых нововведений в архитектуре проекта.
Монолит или микросервисы? Очень жаркая тема для дискуссий. Symfony фреймворк позволяет выбрать любой из этих подходов. Стандартная редакция фреймворка, вероятнее всего более подходит для монолитных проектов из-за своей зависимости от пакета symfony/symfony. Данный пакет содержит все компоненты Symfony плюс несколько фундаментальных бандлов, а так же дополнительный функционал вроде шаблонизатора Twig или Web Profiler. Если вы планируете реализовать Rest API сервис, то безусловно этот дополнительный функционал вам не потребуется и вы спокойно можете его отключить.
Минусом такого подхода может оказаться тот факт, что в папке vendor у вас будет много лишних не используемых компонент. Некоторые разработчики считают, что это делает их приложения более «раздутыми» из-за этих лишних байт. С одной стороны в наше время лишние 15-20 Мб. на диске вовсе не являются проблемой. С другой, если ваша система деплоя подразумевает каждый раз новую установку зависимостей через composer, то лишнее время на установку не нужных компонент выглядит не очень привлекательно. Мне кажется это все-таки более «эстетическая» проблема, а не функциональная, но она имеет место быть.
Помимо фреймворка Symfony, есть Silex, который в противовес предыдущему, включает минимальный набор компонентов и позволяет подключать необходимые по мере надобности. Но делает ли это фреймворк легче или производительней? Нет. Тем не менее Symfony 4 в этом отношении будет больше похож на Silex.
Symfony 4 приложения будут более компактными
Больше нет зависимости от пакета symfony/symfony. Вместо этого, Symfony 4 приложение теперь будет зависеть от отдельных компонентов и некоторых бандлов. Скорее всего это самое значительное изменение в способе разработки приложений на Symfony 4. Причиной этих изменений служит вовсе не экономия места на жестком диске (хотя и это тоже дополнительный плюс). Такой подход открывает множество новых возможностей.
Одной из таких возможностей будет автоматическая конфигурация бандлов. Теперь после установки бандла, Symfony будет автоматически конфигурировать бандл значениями по умолчанию с учетом зависимостей уже присутствующих в вашей системе.
Если посмотреть на текущий Symfony Framework Bundle, то там можно найти множество компонентов, которые могут быть включены или наоборот отключены с помощью конфигурации.
В Symfony 3.2, поддержка компонента Form включена по умолчанию. Возникает вопрос, почему? Скорее всего из-за того, что заранее не возможно угадать будете ли вы использовать формы. Это достаточно популярный компонент, который используется в большинстве приложений и отключение его по умолчанию привело бы к необходимости включать его, а так же другие востребованные компоненты, что сделало бы инициализацию проекта более рутинной.
А теперь представьте: фреймворк больше не зависит от пакета symfony/symfony. Ему теперь требуется лишь symfony/framework-bundle. Автоматическая активация компонента Form теперь реализуется очень просто, достаточно лишь установить компонент symfony/form и он будет активирован и сконфигурирован. Все просто и никакой скрытой магии!
Побочным эффектом такого подхода является небольшой прирост производительности благодаря отсутствию лишних конфигураций и компонентов. Fabien Potencier, обещает в скором времени предоставить результаты некоторых тестов связанных с улучшением производительности.
Переход к «минимализму» так же означает, что теперь Symfony не будет делать предположений о структуре вашего проекта и стеке, который вы используете. Из базового приложения теперь исчезнут файлы README, LICENSE и .htaccess.
Помимо автоматической активации и конфигурации компонентов, логично было бы предположить, что и обратный процесс будет таким же легким. Сейчас разработчики сталкиваются с головной болью при отключении бандлов из проекта. Как правило не достаточно просто удалить пакет. Требуется так же сделать некоторые изменения в файлах конфигурации и в классе AppKernel. C Symfony 4 вы забудете об этом. Нужен компонент Form? Установите пакет symfony/form. Нужен built-in web server? Просто установите symfony/web-server-bundle. Больше не используете Form? Удалите symfony/form и фреймворк позаботится об удалении соответствующих конфигураций. Это круто, это действительно то, чего так не хватает.
Еще один пример для того, чтобы почувствовать этот приятный запах перемен.
Давайте возьмем SensioDistributionBundle, бандл обязательный для стандартной сборки фреймворка. Данный бандл реализует функционал помогающий выполнить некоторые операции после установки всех зависимостей, а так же проверить системные требования для всех компонентов, установленных в вашей системе. Каждый раз когда вы выполняете composer install или composer update в папке web вашего проекта создается файл config.php, проверяющий системные требования. Не кажется ли вам эта схема слегка запутанной? Более того, каждый раз при релизе своего проекта вам необходимо позаботиться об удалении этого файла (вы ведь не забываете это делать?)
Теперь все стало по-другому. Вся логика данного бандла перемещена в пакет symfony/requirements-checker. Хотите проверить системные требования? Установите пакет, выполните проверку, исправьте конфигурацию вашего стека, а затем удалите пакет. Все будет установлено, а затем удалено как будто ничего и не было.
Дополнительно, теперь вы можете вмешиваться в логику работы скриптов, которые выполняются после установки зависимостей через composer (посмотрите на вызовы SensioBundleDistributionBundleComposerScriptHandler::* скриптов в вашем composer.json).
AppBundle в прошлом
Как правило все проекты строятся вокруг одного главного бандла AppBundle. Более продвинутые разработчики делят свои приложения на несколько бандлов, а в некоторых проектах такое разделение и вовсе не требуется. В любом случае AppBundle или как вы его назовете, всегда будет присутствовать в вашем приложении. В Symfony 4 структура несколько переработана и позволяет создавать приложения без бандлов. Просто используйте пространство имен App для любого класса в папке src проекта. Это позволит уменьшить сложность восприятия структуры проекта и сделает ваш код более независимым от фреймворка.
Спасибо за внимание, в следующих постах я напишу об изменении структуры папок проекта, а так же об использовании утилиты make для запуска операций для которых консольные команды Symfony не являются практичными или желательными.
Автор: push
