falbar Symfony 4: Структура фреймворка

Symfony 4: Структура фреймворка

9 декабря 2018 Перевод 1510 0

Структура директорий в 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/ и т. д.

Реклама
Комментариев еще не оставлено
no_avatar