PHP Zend Framework - Zend_Config und globaler Zustand

Question

Ich bin in dem Prozess die Vorteile der Zend_Config_Ini der Bewertung im Vergleich zu einer einfachen konstanten Datei.

z. -

define('DB_HOST',localhost);

//versus

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

Die einzige Sache ist, dass der $ config nicht global zugänglich ist. So müssen Sie Zend_Registry verwenden, um die Anwendungsnutzung zu speichern, ohne jedes Mal zu initiieren.

Dies scheint mehr Komplexität hinzuzufügen als nötig .... bin ich etwas fehlt oder ist Zend_Config + Zend_Registry eine Technik, die besser auf lange Sicht ist wie eine App wächst?

Answer 1

Der Hauptvorteil der Registrierung mit einem config ist der globalen Namensraum zu vermeiden, zu verschmutzen. Sprich: Sie wollen einen Dritten lib und Ihre App und die lib enthalten sowohl eine konstante DB_HOST definieren. Nicht gut.

Darüber hinaus nutzen viele der Fabriken in Zend Framework die Config-Objekt-Instanzen zu erstellen. Zend_Db ist ein gutes Beispiel dafür. Sie geben es nur $this->database und es dauern wird, was es Ihren Adapter instanziert werden muss.

Sie können auch die Registrierung mit benutzerdefinierten Funktionen erweitern, z.B. finder Methoden oder Sachen. Überprüfen Sie die Musterbeschreibung von Fowler.

Answer 2

Ein schöner Vorteil Zend_Config ist, dass Sie nicht auf einer „PHP-Quellcodedatei“ hängen; nur eine INI-Datei tun -. und einige bevorzugen eine INI-Datei anstelle eines PHP eine Modifikation

Und es ist einfacher, eine ini / XML-Datei programmatisch zu ändern - es Klassen / Funktionen, das zu tun

Mit INI-Dateien und Zend_Config, Sie haben auch schöner functionnalities bereits zur Verfügung gestellt; zum Beispiel Vererbung zwischen den Abschnitten (dh Sie einen „allgemeinen“ Abschnitt haben können, und „Staging“ und „Produktion“, das einige Werte überschreiben)

Eine Sache, die über Zend_Config werden insteresting kann, ist auch consitency: Zend Framework, mit Zend_Application, bereits vermutet man eine Konfigurationsdatei haben werden; so, warum nicht ein zweites? Oder sogar wiederverwenden die ersten?

Und es ist das gleiche mit mehreren Klassen des Framework, das mit einer Instanz von Zend_Config konfiguriert arbeiten können, oder werden; wenn Sie bereits, dass man haben, wird es plötzlich leichter; -)

Wenn ich zwischen einer PHP-Datei mit definiert und einer INI-Datei, für Dinge zu wählen habe, die konfigurierbar sind, würde ich wahrscheinlich mit der INI-Datei gehen (Und Zend_Config + Zend_Registry wenn erforderlich) .

Answer 3

Ja, du hast richtig, die Zend sanktioniert Methode zur Konfiguration komplexer ist, eine Reihe von globalen Konstanten als definieren. Die Vorteile, die Sie erhalten, sind

Keine globale Namespace Collisions

Wenn Sie jemals Ihre Anwendung mit einem anderen Projekt müssen integriert werden, mit globalen Konstanten repräsentieren Ihre Anwendung Config-Probleme verursachen kann. Was sind die Chancen hat ein weiteres Projekt eine Konstante DB_HOST benannt? Wie kann ein Entwickler, der Ihr Hybrid-System Tells mit denen Konstanten die Config für Ihre Anwendung gegenüber der integrierten Anwendung ist?

Aufbauend auf der Arbeit anderer

So haben Sie eine einzelne Datei mit allen Konfigurationswerten. Wie wollen Sie, dass in verschiedenen Umgebungen implementieren? (Produktion, Inszenierung, etc.) Die Chancen sind Sie eine intelligente Person, die mit einer Lösung kommen könnte, aber wie wird ein anderer Entwickler in Ihr Projekt kommt nicht zu wissen, wie diese Lösung funktioniert? Wie werden die anderen Module in der Anwendung nicht wissen, wie Sie Ihre globalen Konfigurations lesen?

Zend_Config hat bereits „gelöst“ viele der Probleme. Durch die Übernahme etwas mehr Komplexität und Abstraktion up-front Sie einen bekannten Weg nach vorne bekommen, und können mehr Zeit damit verbringen, auf die Probleme der Anwendung der Lösung statt zu erfinden und unterstützt noch eine weitere Konfiguration System.