Symfony 4: структура приложения

В свое время в Symfony 3 появились каталоги bin/, src/, var/, что по-моему мнению очень удобно и понятно. Мы все привыкли работать с такими каталогами. В свою очередь, Symfony 4 движется в этом же направлении и предлагает обновленную структуру каталогов приложения.

tests/ для тестов

Все тесты теперь будут располагаться непосредственно в каталоге tests/. Ранее в каталоге tests/ всегда присутствовали каталоги с именами бандлов вашего приложения в которых находились тесты. В Symfony 4, приложения не будут (или не обязательно должны) реализовывать код в каком либо бандле. Это позволит определить собственное пространство имен тестов для автозагрузки:

{
    "autoload": {
        "psr-4": {
            "App\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "App\Tests\": "tests/"
        }
    }
}

templates/ для шаблонов

При установке шаблонизатора Twig, теперь будет создаваться каталог templates/ в корне приложения, где и будут размещаться все шаблоны. Мне очень нравится эта идея, потому что каталог Resources, который содержал в себе до этого и публичные файлы (css, js и т.п.) и шаблоны, вносил некоторый дискомфорт. Возможно, что каталог будет называться tpl/, это еще пока окончательно не известно. В целом, перемещение шаблонов из каталога src/ делает приложение более структурированным. Теперь в src/ лежит только код. Класс Kernel, который ранее располагался в папке app/, так же перемещен в src/ где ему и место.

etc/ для конфигураций

Каталог etc/ заменит существовавший ранее app/config. Параметры окружения, которые ранее определялись в файле parameters.yml, теперь конфигурируются с помощью переменных окружения операционной системы. По умолчанию в каталоге etc/ вы обнаружите пустой файл container.yaml (yaml — это не опечатка, в Symfony 4 конфигурационные файлы в формате YAML, теперь имеют расширение yaml, вместо yml)в котором как и прежде можете определять конфигурацию контейнера. Так же там будет файл routing.yaml. В данных файлах вы будете определять только собственные настройки. Компоненты, установленные с помощью Composer, будут хранить свои настройки в отдельных файлах для каждого окружения.

Конфигурацию как и прежде можно будет задавать в трех форматах: YAML, XML, PHP. Помимо конфигурационных файлов, в каталоге etc/ появится bundles.php, который будет представлен массивом бандлов, активных в вашей системе.

//bundles.php
<?php
return [
    'SymfonyBundleFrameworkBundleFrameworkBundle' => ['all' => true],
    'SymfonyBundleTwigBundleTwigBundle' => ['all' => true],
];

Изменения в этот файл будут вноситься автоматически плагином Synfony Flex, при установке или удалении любого бандла в системе с помощью Composer.

var/cache/ только для кеша

Небольшие изменения коснулись каталога var/. Теперь в var/cache/ будет храниться только «вечный» кеш (скомпилированный контейнер и переводы, или кеш доктрины например). Таким образом все файлы в var/cache/ должны иметь свой warmup класс. Никаких временных файлов, только кеш, который не изменяется после деплоя проекта. Это позволит сделать var/cache/ каталог доступным только для чтения. При таком подходе вы сможете работать с read-only файловыми системами (например как на платформах Heroku или SensioCloud).

web/ только для public содержимого

Так же изменилось содержимое каталога web/. Убраны файлы config.php, .htaccess, favicon.ico, apple-touch-icon.png, robots.txt. Не каждый проект нуждается в этих файлах. Если вам потребуются шаблоны для этих файлов, то Symfony 4, предоставит вам возможность опционально получить их.

Изменился и фронт-контроллер. Теперь вместо привычных app.php и app_dev.php будет присутствовать один файл index.php для всех окружений:

if (!getenv('APP_ENV')) {
    (new Dotenv())->load(__DIR__.'/../.env');
}

if (getenv('APP_DEBUG')) {
    if (isset($_SERVER['HTTP_CLIENT_IP'])
        || isset($_SERVER['HTTP_X_FORWARDED_FOR'])
        || !(in_array(@$_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1']) || PHP_SAPI === 'cli-server')
    ) {
        header('HTTP/1.0 403 Forbidden');
        exit('You are not allowed to access this file.');
    }

    Debug::enable();
}

// Request::setTrustedProxies(['0.0.0.0/0'], Request::HEADER_FORWARDED);

$kernel = new Kernel(getenv('APP_ENV'), getenv('APP_DEBUG'));
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);

Используем переменные окружения для конфигурации

Настройки, специфичные для конкретной платформы и окружения, ранее принято было хранить в конфигурационном файле app/config/parameters.yml. Теперь такие параметры следует задавать с помощью переменных окружения. Это дает некоторые преимущества перед использованием parameters.yml. Например вы можете динамически менять данные параметры без необходимости чистить кеш. Переменные окружения можно использовать совместно в нескольких приложениях и языках программирования. Наконец вы можете администрировать данные параметры с помощью сторонних приложений.

На боевом сервере такой подход выглядит весьма привлекательно. Но в момент разработки приложения, использование переменных окружения может доставить много неудобств. Symfony 3.3 уже поставляется с компонентом Dotenv, который призван решить проблему. В корне вашего приложения будет располагаться файл .env, в котором можно определить переменные окружения. Компонент Dotenv, позволяет «переключаться» между использованием .env файла и реальными переменными окружения.

Как насчет Makefile?

Во многих проектах существуют сценарии, для которых использование скриптов, написанных на PHP, не совсем целесообразно(например такие вещи как рестарт веб-сервера или перезагрузка конфигурации php-fpm после очередного деплоя).

Для этих целей предлагается использовать Makefile. Утилита make знакома всем. Ее использование лучше, чем выполнение скриптов с помощью Composer (если вы прописали их в composer.json). Так же утилита make выполняется централизованно на вашей системе и не зависит от PHP. Давайте рассмотрим реальный пример, в Symfony есть консольные команды для очистки и разогрева кеша. Использование двух команд в одном процессе работает не так как нужно, потому что PHP не умеет перезагружать классы если они изменились. Эту проблему можно легко решить с помощью вот такого Makefile:

cache-clear:
    @test -f bin/console && bin/console cache:clear --no-warmup || rm -rf var/cache/*
.PHONY: cache-clear

cache-warmup: cache-clear
    @test -f bin/console && bin/console cache:warmup || echo "cannot warmup the cache (needs symfony/console)"
.PHONY: cache-warmup

Именно такой файл вы получите в стандартной сборке Symfony 4 приложения.

Я столкнулся с небольшой проблемой тестируя установку на Windows машине. Если для nix систем утилита make является стандартной, то на Windows нужно немного постучать в бубен. Проблема не в том, чтобы найти реализацию make для Windows, а в том, что в сценариях присутствуют вызовы таких команд test, rm и т.п. Обсуждение данного вопроса было тут.

Для себя я определил два способа решения этой проблемы:

1. Использовать GitBash в качестве терминала. Если вы используете Git, то скорее всего GitBash присутствует в вашей Windows системе.
2. Сегодня я настраивал свою любимую IDE PhpStorm на использование Cygwin терминала по умолчанию. И мне это решение понравилось больше, чем использование GitBash.

На этом пока все. Впереди материал о первых впечатлениях и инструкция по сборке приложения с помощью плагина Symfony Flex.

Автор: shude

Источник