4 Stimmen

Wie lassen sich Konfigurationsoptionen intern am besten darstellen?

Ich suche also nach einer Reihe von Möglichkeiten, meine Konfigurationsdaten zu speichern. Ich glaube, ich habe es auf 3 Möglichkeiten eingegrenzt:

Nur eine einfache Variable

$config = array(
    "database" => array(
        "host" => "localhost",
        "user" => "root",
        "pass" => "",
        "database" => "test"
    )
);

echo $config['database']['host'];

Ich denke, dass dies einfach zu veränderlich ist, während die Konfigurationsoptionen nicht geändert werden können sollten.

Eine modifizierte Standardklasse

class stdDataClass {

    // Holds the Data in a Private Array, so it cannot be changed afterwards.
    private $data = array();

    public function __construct($data)
    {
        // ......
       $this->data = $data;
        // .....
    }

   // Returns the Requested Key
   public function __get($key)
   {
        return $this->data[$key];
   }

   // Throws an Error as you cannot change the data.
   public function __set($key, $value)
   {
         throw new Exception("Tried to Set Static Variable");
    }
}

$config = new stdStaticClass($config_options);
echo $config->database['host'];

Im Grunde kapselt es das obige Array in ein Objekt ein und sorgt dafür, dass das Objekt nicht verändert werden kann.

Oder eine statische Klasse

 class AppConfig{
    public static function getDatabaseInfo()
    {
          return array(
            "host" => "localhost",
            "user" => "root",
            "pass" => "",
            "database" => "test"
        );   
    }
    // .. etc ...
}

$config = AppConfig::getDatabaseInfo();
echo $config['host'];

Dies bietet die ultimative Unveränderlichkeit, aber es bedeutet auch, dass ich die Klasse manuell bearbeiten müsste, wenn ich die Daten ändern wollte.

Welche der oben genannten Optionen sollten Ihrer Meinung nach am besten für die Speicherung von Konfigurationsoptionen verwendet werden? Oder gibt es einen besseren Weg?

3voto

gabrielk Punkte 573

Von diesen 3 Optionen ist eine statische Methode wahrscheinlich die beste.

In Wirklichkeit geht es bei "dem Besten" darum, was für Sie am einfachsten und konsistentesten ist. Wenn der Rest Ihrer Anwendung keine OO-Codes verwendet, können Sie sich auch für Option 1 entscheiden. Wenn Sie letztlich wollen, um eine ganze db Abstraktionsschicht zu schreiben, Option #2.

Ohne mehr darüber zu wissen, welche Ziele Sie verfolgen und wie der Rest Ihrer App aussieht, ist es so, als würden Sie jemanden fragen, welches das beste Auto ist - je nachdem, ob Sie einen Sportwagen, einen Lastwagen oder ein Motorrad suchen, fällt die Antwort anders aus.

1voto

NotMe Punkte 86089

Ich würde mich für das entscheiden, was hinter Tür Nr. 3 ist.

Sie ist leichter zu lesen und zu verstehen als die Nummer 2 und scheint Ihren Bedürfnissen besser zu entsprechen als die Nummer 1.

1voto

leepowers Punkte 36580

Schauen Sie sich diese Frage an, um Ideen für die Speicherung der Konfigurationsdaten in einer separaten Datei zu erhalten:

Der schnellste Weg, leicht editierbare Konfigurationsdaten in PHP zu speichern?

Ich würde Methode #2 verwenden, die die Konfigurationsdaten als Array aus einer externen Datei zieht.

1voto

Gordon Punkte 304254

El am besten ist der Weg, der für Ihre Anwendung am besten geeignet ist.

Für eine kleine Anwendung kann es völlig ausreichend sein, ein Array zu verwenden, auch wenn es veränderbar ist. Wenn niemand außer Ihnen da ist, um es zu ändern, muss es nicht unveränderlich sein.

Der zweite Ansatz ist sehr flexibel. Er kapselt Daten ein, weiß aber nichts über sie. Sie können sie frei weitergeben, und die konsumierenden Klassen können daraus nehmen, was sie brauchen. Sie ist generisch genug, um wiederverwendet werden zu können, und koppelt die Konfigurationsklasse nicht an die konkrete Anwendung. Sie könnten auch eine Schnittstelle mit dieser oder ähnlichen Klassen verwenden, um Typ-Hinweise in Ihren Methodensignaturen zu ermöglichen, um anzuzeigen, dass eine Config erforderlich ist. Nennen Sie sie einfach nicht stdDataClass, sondern benennen Sie sie nach ihrer Rolle: Config.

Ihre dritte Lösung ist sehr konkret. Sie kodiert eine Menge Annahmen darüber, was Ihre Anwendung benötigt, in die Klasse und macht es zur Aufgabe der Klasse, diese Daten zu kennen und über Getter und Setter bereitzustellen. Je nach der Anzahl der Komponenten, die konfiguriert werden müssen, kann es sein, dass Sie am Ende eine Menge spezifischer Getter haben. Die Chancen stehen gut, dass Sie das Ganze für Ihre nächste Anwendung neu schreiben müssen, nur weil Ihre nächste Anwendung andere Komponenten hat.

Ich würde mich für den zweiten Ansatz entscheiden. Werfen Sie auch einen Blick auf Zend_Konfiguration da es alle Ihre Anforderungen bereits erfüllt und Sie das Config-Objekt aus XML, Ini und einfachen Arrays initiieren können.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X