PHP Zend Framework - Zend_Config и глобальное состояние

Question

Я нахожусь в процессе оценки преимуществ Zend_Config_Ini по сравнению с использованием простого файла констант.

например ,-

define('DB_HOST',localhost);

//versus

$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host;   // prints "dev.example.com"

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

Это, по-видимому, добавляет больше сложности, чем необходимо....я что-то упускаю или Zend_Config + Zend_Registry - это метод, который в долгосрочной перспективе становится лучше по мере роста приложения?

Answer 1

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

Кроме того, многие фабрики в Zend Framework используют объект config для создания экземпляров. Zend_Db является хорошим примером этого.Вы просто передаете это $this->database и ему потребуется все необходимое для создания экземпляра вашего адаптера.

Вы также можете расширить реестр пользовательскими функциями, напримерметоды поиска или что-то в этом роде.Проверьте описание узора автор: Фаулер.

Answer 2

Приятным преимуществом Zend_Config заключается в том, что вы не зависите от "файла исходного кода PHP". ;достаточно просто .ini-файла - и некоторые предпочитают изменять .ini-файл вместо PHP-файла.

И проще изменить файл .ini / XML программно - для этого есть классы / функции !

С файлами .ini и Zend_Config, у вас также уже есть приятные функциональные возможности ;например, наследование между разделами (т. е. у вас может быть раздел "generic", а также "staging" и "production", которые перезаписывают некоторые значения)

Вещь, которая может вызывать интерес Zend_Config, тоже является согласованностью :Фреймворк Zend, с Zend_Application, уже предполагает , что у вас будет один конфигурационный файл ;итак, почему бы не сделать второй ?Или даже повторно использовать первый ?

И это то же самое с несколькими классами Фреймворка, которые могут работать или быть сконфигурированы с экземпляром Zend_Config ;если у вас уже есть это, внезапно становится легче ;-)

Если бы мне пришлось выбирать между PHP-файлом с определениями и файлом .ini, для настраиваемых функций я бы, вероятно, выбрал файл .ini (И Zend_Config + Zend_Registry когда это необходимо).

Answer 3

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

Отсутствие конфликтов глобальных пространств имен

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

Опираясь на работу других

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

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