PHP Lang
  1. PHP Lang
  3. Yii2: параметры конфигурации vs. const / define
Intereting Posts
Нужно ли откатываться, если фиксация завершается неудачей? Перенаправление и маршрутизация URL-адреса Codeigniter Что такое регулярное выражение для решения этой проблемы? PCRE скомпилирован без поддержки UTF php imagemagick создает TIFF с черепичной пирамидой Cake PHP присоединился к запросу, возвращенному как ассоциативный массив Роль и разрешения Laravel с полномочиями PHP preg_replace: Нечувствительность к регистру с чувствительностью к регистру Как запомнить опубликованные поля в формах для выпадающих элементов? Внешний ключ для нескольких таблиц Laravel – проверьте, не пусто ли Привет, У меня есть запрос с базой данных Асинхронная оболочка exec в PHP Не удалось перезагрузить сервер apache2 на ubuntu 14.04 Большие загрузки файлов с использованием FileReader и php

Yii2: параметры конфигурации vs. const / define

Когда мне следует использовать что?

У меня есть возможность определить константы в файле сценария ввода index.php, как это рекомендуется в руководстве Yii2: константы . Или я мог бы использовать параметры в конфигурации, объясненные в руководстве YII2: params . Оба они предназначены для одного приложения и не являются глобальными.

В настоящее время мне кажется, что параметры немного менее удобны, если я хочу объединить такие значения: 

define('SOME_URL', 'http://some.url'); define('SOME_SPECIALIZED_URL', SOME_URL . '/specialized');

Кроме того, доступ – бит больше кода ( Yii::$app->params['something'] ) по сравнению с константами.

Итак, когда я должен использовать или что-то использовать?

Небольшое обновление : в PHP 7 define() поддерживает массивы, поэтому всю структуру params можно настроить как константу. Вероятно, лучше поддерживаются IDE.

Я склонен использовать параметры приложения Yii. Основная причина этого – значения, которые хранятся в этих параметрах, как правило, изменяются в зависимости от среды, в которой выполняется код. Поэтому у меня будет построенная система сборки (я использую Phing ) и вытаскивает настройки из не- файл с контролируемой версией, такой как build.properties.

Таким образом, в моей среде разработки будут загружены любые настройки базы данных разработчиков, настройки домена dev, а также адресные дескрипторы api и т. Д., И правильные производственные значения будут использоваться, когда сборка будет запущена на реальном сервере.

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

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