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

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

3 голосов
/ 27 ноября 2009

Я нахожусь в процессе оценки преимуществ 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 - метод, который лучше в долгосрочной перспективе по мере роста приложения?

Ответы [ 3 ]

4 голосов
/ 27 ноября 2009

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

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

Вы также можете расширить реестр с помощью пользовательских функций, например, методы поиска или тому подобное. Проверьте описание по Фаулеру.

1 голос
/ 27 ноября 2009

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

Нет глобальных коллизий пространства имен

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

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

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

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

1 голос
/ 27 ноября 2009

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

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

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


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

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


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

...