Конфигурация

Конфигурация обычно касается разных частей приложения (таких, как инфраструктураи сертификаты безопасности) и разных окружений (разработки, производства). Поэтому Symfony рекомендует вам разделять конфигурацию приложения на три части.

Конфигурация, связанная с инфраструктурой

Это опции, которые изменяются от машины к машине (например, от вашей машины разработки к серверу производства), но которые не изменяют поведение приложения.

Best Practice

Определите опции конфигурации, связанной с инфраструктурой, в качестве переменных окружения. Во время разработки, используйте файл .env в корне вашего проекта для того, чтобы установить их.

По умолчанию, Symfony добавляет эти типы опций к файлу .env при установке новых зависимостей в приложении:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# .env
###> doctrine/doctrine-bundle ###
DATABASE_URL=sqlite:///%kernel.project_dir%/var/data/blog.sqlite
###< doctrine/doctrine-bundle ###

###> symfony/swiftmailer-bundle ###
MAILER_URL=smtp://localhost?encryption=ssl&auth_mode=login&username=&password=
###< symfony/swiftmailer-bundle ###

# ...

Эти опции не определены внутри файла config/services.yaml, так как они не имеют ничего общего с поведением приложения. Другими словами, вашему приложению наплевать на локацию вашей БД или сертификаты для доступа к ней, если БД сконфигурирована корректно.

Caution

Имейте в виду, что сброс содержания переменных $_SERVER или $_ENV, или вывод содержания phpinfo() отобразит значения переменных окружения, отображая чувствительную информацию вроде аккредитации БД.

Каноничные параметры

Best Practice

Определите всепеременные окружения вашего приложения в файле .env.dist.

Symfony включает в себя файл конфигурации под названием .env.dist в корне проекта, который хранит каноничный список параметров конфигурации приложения.

Когда определяется новая переменная окружения для приложения, вам также стоит добавить её в этот файл и зафиксировать изменения вашей системе контроля версий, чтобы ваши коллеги могли обновить свои файлы .env.

Конфигурация, связанная с приложением

Best Practice

Определите опции конфигурации, связанные с поведением приложения в файле config/services.yaml.

Файл services.yaml содержит опции, используемые приложением для изменения его поведения, такие как отправка уведомлений по электронной почте, или включение переключателей функций. Определение этих значений в файле .env добавит дополнительный слой конфигурации, который не нужен, так как вам не нужно,чтобы эти значения конфигурации изменялись на каждом сервере.

Опции конфигурации, определённые в services.yaml могут отличаться от окружения к окружению. Поэтому Symfony поддерживает определения файлов config/services_dev.yaml и config/services_prod.yaml, чтобы вы могли переопределять конкретные значения для каждого окружения.

Константы против опций конфигурации

Одна из наиболее распространённых ошибок при определении конфигурации приложения - создавать новые опции для значений, которые никогда не изменяются, например, количество объектов для пронумерованных результатов.

Best Practice

Используйте константы для определния опций конфигурации, которые редко изменяются.

Традиционный подход для определения опций конфигурации привёл к тому, что многие приложения Symfony включают в себя следующую опцию, которая будет использована для контроля количества постов, отображаемых на домашней странице блога:

1
2
3
# config/services.yaml
parameters:
    homepage.num_items: 10

Если вы делали что-то подобное в прошлом, то есть вероятность, что вам на самом деле никогда не нужно было изменять это значение. Создание опции конфигурации для значения, которое вы не собираетесь когда-либо конфигурировать просто бессмысленно. Мы рекомендуем определять эти значения в качестве констант в вашем приложении. Вы можете, например, определить константу NUM_ITEMS в сущности Post:

1
2
3
4
5
6
7
8
9
// src/Entity/Post.php
namespace App\Entity;

class Post
{
    const NUM_ITEMS = 10;

    // ...
}

Главное преимущество в определении констант заключается в том, что вы можете использовать их значения всюду в вашем приложении. При использовании параметров, они доступны только из мест с доступом к контейнеру Symfony.

Константы могут быть использованы, к примеру, в ваших шаблонах Twig, благодаря функции constant():

1
2
3
<p>
    Displaying the {{ constant('NUM_ITEMS', post) }} most recent results.
</p>

А сущности Doctrine и хранилища теперь могут с лёгкостью получать доступ к этим значениям, в то время, как к параметрам контейнера - нет:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
namespace AppBundle\Repository;

use Doctrine\ORM\EntityRepository;
use AppBundle\Entity\Post;

class PostRepository extends EntityRepository
{
    public function findLatest($limit = Post::NUM_ITEMS)
    {
        // ...
    }
}

Единственным заметным недостатком использования констант для такого типа значений конфигурации является то, что вы не можете легко переопределить их в ваших тестах.

Именование параметров

Best Practice

Имя ваших параметров конфигурации должно быть максимально коротким и включать в себя общий префикс для всего приложения.

Использование app. в качестве префикса ваших параметров является общей практикой для избежания коллизий Symfony и параметров сторонних пакетов и библиотек. Далее, используйте одно или два слова, чтобы описать цель параметра:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# config/services.yaml
параметры:
    # не делайте так: 'dir' слишком общий и не несёт никакого значения
    app.dir: '...'
    # делайте так: короткие, но лёгкие для понимания имена
    app.contents_dir: '...'
    # можно использовать точки, нижние подчёркивания, дефисы или ничего из этого,
    # но всегда используйте один и тот же формат для всех параметров
    app.dir.contents: '...'
    app.contents-dir: '...'

Далее: Organizing Your Business Logic

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.