PHP Zend Framework - Zend_Config e estado global

Question

Eu estou no processo de avaliação dos benefícios da Zend_Config_Ini em vez de utilizar um arquivo constante simples.

por exemplo. -

define('DB_HOST',localhost);

//versus

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

A única coisa é que o $ config não é globalmente acessível. Então você precisa usar Zend_Registry a loja para o uso do aplicativo, sem ter que iniciar cada tempo.

Este parece acrescentar mais complexidade do que o necessário .... estou faltando alguma coisa ou é Zend_Config + Zend_Registry uma técnica que é melhor no longo prazo, como um aplicativo cresce?

Answer 1

A principal vantagem de usar o Registro com uma configuração é evitar poluir o namespace global. Diga, você quer incluir um terceiro lib partido e seu aplicativo ea lib tanto definir um DB_HOST constante. Não é bom.

Além disso, muitas das fábricas em Zend Framework utilizar o objeto de configuração para criar instâncias. Zend_Db é um bom exemplo disso. Você apenas passá-lo $this->database e vai levar o que ele precisa para instanciar o seu adaptador.

Você também pode estender o registro com funcionalidade personalizada, por exemplo, métodos Finder ou coisas assim. Verifique a padrão descrição por Fowler.

Answer 2

Uma boa vantagem de Zend_Config é que você não dependem de uma "PHP arquivo de código fonte"; apenas um arquivo ini vai fazer -. e alguns preferem modificar um arquivo .ini em vez de um PHP

E é mais fácil modificar um arquivo / XML ini programaticamente - existem classes / funções para fazer isso

Com arquivos .ini e Zend_Config, você também tem agradáveis ??functionnalities já previstas; por exemplo, a herança entre as seções (ou seja, você pode ter uma seção "genérico", e "encenação" e "produção" que substituir alguns valores)

Uma coisa que pode ser insteresting sobre Zend_Config, também, é consitency: Zend Framework, com Zend_Application, já supõe que você vai ter um arquivo de configuração; assim, por que não um segundo? Ou mesmo re-utilizar o primeiro?

E é o mesmo com várias classes do Framework, que pode funcionar ou ser configurada com uma instância de Zend_Config; se você já tem que se, de repente se torna mais fácil; -)

Se eu tivesse que escolher entre um arquivo PHP com define e um arquivo ini, para as coisas que são configuráveis, eu provavelmente ir com o arquivo .ini (E Zend_Config + Zend_Registry quando necessário) .

Answer 3

Sim, você está correto, usando o método Zend sancionada para a configuração é mais complexa do que a definição de uma série de constantes globais. As vantagens que você tem são

No espaço global Colisões

Se você precisar para integrar sua aplicação com outro projeto, tendo constantes globais representam sua configuração do aplicativo pode causar problemas. Quais são as chances outro projeto tem uma constante chamada DB_HOST? Como pode um desenvolvedor que está usando seu tell sistema híbrido que constantes são a configuração para sua aplicação contra a aplicação integrada?

Com base no trabalho dos outros

Assim, você tem um único arquivo com todos os seus valores de configuração. Como você está indo para implantar isso em ambientes diferentes? (Produção, staging, etc.) As chances são de que você é uma pessoa inteligente, que poderia chegar a uma solução, mas como é outro desenvolvedor que entram em seu projeto vai saber como isso funciona solução? Como outros módulos na sua aplicação vai saber como ler sua configuração global?

Zend_Config já "resolvido" muitos dos problemas. Ao assumir um pouco mais complexidade e abstração up-front que você começa um caminho conhecido para a frente, e pode passar mais tempo na resolução dos problemas de sua aplicação em vez de inventar e apoiando mais um sistema de configuração.