Структура директорий в Symfony 3 слегка отличалась от Symfony 2. В 4-й версии Symfony структура также была переработана. В основном были произведены изменения и правки для поддержания новых функций и лучших методик.
В 3-й версии Symfony структура директорий напоминала стандартную Unix, было мало подкаталогов. Symfony 4 продолжает двигаться в том же направлении.
Вам поможет использование известных названий каталогов. Использование bin/, src/, var/ - отличный шаг вперед. Вместо app/ в Symfony 4 используется etc/. Такая идея предлагалась и для Symfony 3, но была отвержена по причинам, которые уже не важны.
Изменения: etc/ сменили на config/ после долгих обсуждений в коммьюнити. Каталог web/ был заменен на public/. Статьи в блоге о Symfony 4 были обновлены, чтобы отразить эти изменения.
Тестирование в tests
Тесты перешли в высокоуровневый каталог tests/. Это предлагалось и ранее, однако смысл добавлять такое изменение появился только сейчас, когда стали использоваться приложения с меньшим количеством пакетов. Новая функция также позволяет объявить конкретное имя теста для автозагрузки:
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"App\\Tests\\": "tests/"
}
}
}
Шаблоны в templates
Шаблоны стали первоклассными «гражданами» в новом высокоуровневом каталоге templates/. Может быть, tpl был бы более разумным вариантом по сравнению с другими названиями каталогов из 3 букв?
А почему не views? Views - изначальное имя, которые я выбрал ранее потому, что оно было короче templates. Это было ошибкой, ведь View сам по себе имеет значение. Наконец, эта ошибка была исправлена.
Размещение шаблонов на корневом уровне упрощает работу с веб-дизайнерами. Эта папка создается только при установке Twig.
При перемещении шаблонов можно зарезервировать src/ только для классов PHP, и больше здесь не будет никаких ресурсов. Еще одно последствие меньшего использования пакетов.
Конфигурация в config
Новый каталог config/ является эквивалентом текущего каталога app/config/. Но используется совсем другая компоновка. parameters.yml и parameters.yml.dist были убраны.
Основной точкой входа для контейнера является пустой container.yaml, который можно использовать для определения ваших собственных ресурсов и параметров. Конфигурации для пакетов, которые вы устанавливаете через composer, хранятся в виде отдельных файлов. Для каждого пакета и среды предназначен один пакет. То же самое касается конфигурации маршрутизации. Это мягкое требование для автоконфигурации позволяет улучшить организацию файлов.
Файлы конфигурации могут быть написаны на PHP, XML или YAML, как и раньше. Единственное отличие заключается в использовании стандартного расширения .yaml вместо текущего .yml.
Одним из основных изменений является введение файла bundles.php, на который ссылаются установленные пакеты.
По одному файлу на пакет и bundles.php - это две основные концепции, которые позволяют Symfony автоматически управлять пакетами и их конфигурациями.
Исходный код в src
Класс Kernel был перенесен в src/, где ему и место. Содержание этого каталога сильно отличается от Symfony 2. Во-первых, он использует типаж MicroKernelTrait. Кроме того, он реализует логику для загрузки пакетов из bundles.php и для чтения различных файлов конфигурации пакетов. Логика работает так же, как в Symfony 3.3. Например, код, загружающий файлы конфигурации контейнера, выглядит следующим образом:
protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader)
{
$confDir = dirname(__DIR__).'/config';
$loader->import($confDir.'/packages/*'.self::CONFIG_EXTS, 'glob');
if (is_dir($confDir.'/packages/'.$this->getEnvironment())) {
$loader->import($confDir.'/packages/'.$this->getEnvironment().'/**/*'.self::CONFIG_EXTS, 'glob');
}
$loader->import($confDir.'/container'.self::CONFIG_EXTS, 'glob');
}
Временные файлы в var
var/ похож на свой аналог в Symfony 3, однако были добавлены некоторые незначительные изменения в лучших практиках.
var/cache/ теперь должен использоваться только для хранения долгосрочного кэшированного содержимого: например, скомпилированных файлов контейнера, скомпилированных переводов или прокси Doctrine. Никаких временных файлов. В принципе, все, что хранится в var/cache, должно иметь возможность генерировать файлы кэша. Эти файлы никогда не должны обновляться после развертывания, благодаря чему станут доступны файловые системы, которые можно только читать.
А как же временные файлы? Используйте другой каталог, например var/tmp/. Или просто стандартный каталог Unix /tmp.
Если вы будете следовать этому методу, в какой-то момент мы сможем гарантировать каталог, доступный только для чтения, - /var/cache. Наличие каталогов, доступных только для чтения, является требованием некоторых хостинговых платформ, таких как Heroku или SensioCloud, и помогает масштабировать приложение. Вероятно, эта идея не для Symfony 4.0.
Веб-файлы в public
Я уже упоминал единственный контроллер веб-запросов в public/. Практически все остальные файлы были убраны. Нет ни config.php, ни .htaccess, ни favicon.ico, ни apple-touch-icon.png, ни даже robots.txt. Не во всех проектах нужны эти файлы. Если вы хотите получить «скелеты» этих файлов, я вам, конечно, помогу.
Все опционально
Одно из отличий Symfony 3 заключается в том, что все каталоги первого уровня являются необязательными. Не используете шаблоны для своего API? Нет необходимости создавать каталог templates/. Каталоги ведь все равно создаются по запросу.
При использовании composer для добавления нового пакета Symfony 4 применяет эту новую структуру каталогов, автоматически регистрируя пакет в bundles.php, копируя некоторую важную конфигурацию в config/ и т. д.