Лучшие практики в Symfony 2 — Конфигурация

Приветствую вам дорогие мои читатели, а так же тех кто, как то случайно наткнулся на мой блог. Сегодня мой пост будет посвящен переводу следующей главы из книги Symfony Best Practices.

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

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

Конфигурация зависящая от среды выполнения

Лучшая практика
Размещайте все параметры зависящие от среды выполнения приложения в файле app/config/parameters.yml

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

# app/config/parameters.yml
parameters:
    database_driver:   pdo_mysql
    database_host:     127.0.0.1
    database_port:     ~
    database_name:     symfony
    database_user:     root
    database_password: ~

    mailer_transport:  smtp
    mailer_host:       127.0.0.1
    mailer_user:       ~
    mailer_password:   ~

    # ...

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

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

Лучшая практика
Размещайте все параметры вашего приложения в файле app/config/parameters.yml.dist

Начиная с версии 2.3, Symfony 2 содержит конфигурационный файл parameters.yml.dist, который содержит список канонических параметров для приложения.

Каждый раз когда вы добавляете новый параметр конфигурации для вашего приложения, вам необходимо добавить его в список канонических параметров, а так же отправить изменения в вашу систему контроля версий. Затем, когда разработчик будет обновлять свой проект или разворачивать его на сервере, Symfony 2 проверит, есть ли разница между списком канонических параметров из файла parameters.yml.dist и параметрами из файла parameters.yml. В случае, если есть разница, то Symfony 2 запросит уточнение значения для отсутствующего параметра и добавит его в файл parameters.yml.

Конфигурация приложения

Лучшая практика
Определяйте все настройки описывающие поведение вашего приложения в файле app/config/config.yml

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

Параметры конфигурации определенные в файле config.yml, как правило незначительно отличаются друг от друга в зависимости от того в какой среде выполнения работает приложение. Именно по этому Symfony 2 уже содержит файлы app/config/config_dev.yml и app/config/config_prod.yml, для того, что бы вы могли изменить необходимые значения параметров для различных сред выполнения вашего приложения.

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

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

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

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

# app/config/config.yml
parameters:
    homepage.num_items: 10

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

// src/AppBundle/Entity/Post.php
namespace AppBundle\Entity;

class Post
{
    const NUM_ITEMS = 10;

    // ...
}

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

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

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

Репозитории и сущности Doctrine могут легко получить доступ к константам, в то же время они не могут легко получить доступ к параметрам контейнера:

namespace AppBundle\Repository;

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

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

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

Семантическая конфигурация: Не делайте этого!

Лучшая практика
Не определяйте семантическую конфигурацию для контейнера в ваших бандлах

Как объясняется в статье Как загрузить конфигурацию сервиса в бандле, для бандлов Symfony существует два варианта, как загружать конфигурацию: нормальный с помощью файла services.yml и с помощью семантической конфигурации при реализацией специального *Extension класса.

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

Размещение изменяемых параметров полностью вне Symfony 2

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

Оригинал