Подтвердить что ты не робот

Проверьте, что в режиме "dev" внутри контроллера с Symfony

При использовании режима dev с приложением Symfony2.x, обычно работает в локали. Следовательно, такая функция работает не так, как ожидалось (например, попытайтесь получить текущий IP-адрес под локальным хостом). Это может быть проблемой, например. когда вы пытаетесь использовать такую ​​веб-службу на основе ip. Следовательно, Я просто хочу знать, как проверить внутри контроллера, если приложение Symfony2 работает в режиме dev или не. Таким образом, можно установить поведение контроллера в зависимости от режима.

Любая идея?

4b9b3361

Ответ 1

Чтобы получить текущую среду в Controller, вы можете использовать:

$this->container->getParameter('kernel.environment');

Итак, вы просто положили это в оператор if(), чтобы проверить, равно ли оно dev.

Ответ 2

Как и в Symfony 2,5, это можно сделать как:

$this->container->get('kernel')->getEnvironment();

Непосредственно запрос ядра этой среды выглядит лучше, чем поиск параметра.

Ответ 3

Так как вы хотите знать, находитесь ли вы в режиме dev (не обязательно в среде с именем "dev" ), вы можете извлечь ядро ​​из контейнера службы и проверить возвращаемый метод isDebug:

$kernel = $this->get('kernel');
$devMode = $kernel->isDebug();

Как указано в документации (акцент мой),

Важным, но не связанным с темой среды является true или falseаргумент как второй аргумент конструктору AppKernel. Это указывает, должно ли приложение работать в режиме "отладки". Вне зависимости от среда, приложение Symfony может быть запущено с установленным режимом отладки true или false. Это затрагивает многие вещи в приложении, такие как отображение stacktraces на страницах ошибок или если файлы кеша динамически перестраивается по каждому запросу. Хотя это не требование, отладка режим, как правило, установлен в true для тестовых сред dev и false для среды prod.

Внутренне значение режима отладки становится kernel.debug параметр, используемый внутри контейнера службы.

Ответ 4

Вот 2017 и Symfony 3. 3+ версия с использованием инъекции в конструктор.

Вместо того, чтобы передавать все приложение (= контейнер), вы можете передать только нужный параметр:

1. Сервисный конфиг

# app/config/services.yml
services:
    _defaults:
        autowire: true

    App\Controller\SomeController:
        arguments: ['%kernel.environment%']

Если вы не понимаете этот синтаксис, проверьте этот пост, объясняя новости Symfony DI в примерах до/после.

2. Контроллер

namespace App\Controller;

final class SomeController
{
    /**
     * @var string
     */
    private $environment;

    public function __construct(string $environment)
    {
        $this->environment = $environment;
    }

    public function someAction()
    {
        $this->environment...
        // any operations you need
    }
}


Почему не следует передавать контейнер в контроллер?

Самая важная вещь в коде - это согласованность.

  • Если вы предпочитаете статические и сервисные локаторы (= сервис, который вы можете передать куда угодно, чтобы получить любой другой сервис), используйте его.

  • Если вы предпочитаете внедрение конструктора, граф зависимостей дерева (! = Циклические зависимости), используйте его.

Смешивание этой концепции может быть вам полезно, если вы знаете, почему вы использовали их таким образом. Но здесь можно поиграть в The Broken Window Theory (прекрасно описанную версию Coding Horror). Любой, кто придет к коду , с большей вероятностью выберет версию, которая не предназначена для использования таким образом.

Неоднозначность в коде - это первое приглашение к унаследованному коду

Я руководил командами многих приложений, которые начинались с простого $this->container в коде и через пару лет в итоге позвали меня на помощь, как переписать или провести рефакторинг всего статического ада.

Ответ 5

Для Symfony 4.x и выше

Если вы используете .env для хранения переменных среды, вы можете получить к ним доступ на любом контроллере, просто используя $_ENV['name-of-variable']

Для установки по умолчанию доступна переменная $_ENV["APP_ENV"], которая сообщит вам, находитесь ли вы в режиме разработки или нет.


Используйте print_r($_ENV);, чтобы увидеть все доступные переменные среды.

[ps - это также работает для Symfony 3.4]