$GLOBALS oder Static für Konfigurationen?

[MB]

moin Community,

um Konfigurationen in einem Framework zu setzten, kann man ein Superglobale assoziatives Array verwnden $GLOBALS oder eine Klasse Config::get() - mein Wissensstand.

Frage: Was sind "Pros" und "Cons" dieser beiden Methoden?

Nebenfrage: ich habe aus SelfHTML kreisen gehört das es nicht gut sei, Superglobale Variablen zu verwenden. Bei globale Variablen kann ich nur erfahrungsgemäß zustimmen, aber bei einem Superglobalen assoziativem Array wie $SESSION oder $SERVER frage ich mich warum?

vgl MB

[TS]

Hello,

um Konfigurationen in einem Framework zu setzten, kann man ein Superglobale assoziatives Array verwnden $GLOBALS oder eine Klasse Config::get() - mein Wissensstand.

Man kann inzwischen auch Array of Const benutzen.

Was man bentutzen, hängt immmer davon ab, ob die Konfiguration während der Laufzeit verändert werden darf, oder nicht.

[...] bei einem Superglobalen assoziativem Array wie $SESSION oder $SERVER

Die heißen $_SESSION und $_SERVER.

Ich bevorzuge es, die Konfiguration in leicht lesbaren INI-Dateien extern abzuspeichern und in den Modulen, in denen darauf zugegriffen werden soll, einen hart codierten Vorgabewert einzusetzen für den Fall, dass der Konfigurationsparameter fehlt.

Den Zugriff auf die Konfigurationsparamter mit einem Getter zu schützen, macht das ganze Skript leichter lesbar (verständlicher) und etwas sicherer gegen unbeabsichtigte Veränderung.

Ob man dann Veränderungen trotzdem zurückschreiben lässt in die Konfigurationsdateien muss der Einzelfall ergeben. Diese Möglichkeit würde Programme allerdings "lernfähig" machen.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

um Konfigurationen in einem Framework zu setzten, kann man ein Superglobale assoziatives Array verwnden $GLOBALS oder eine Klasse Config::get() - mein Wissensstand.

Frage: Was sind "Pros" und "Cons" dieser beiden Methoden?

Es ist kein Unterschied, ob du eine globale Variable oder ein Singleton verwendest. Das läuft prinzipiell auf dasselbe hinaus.

Die generelle Frage ist jedoch, möchtest du einen globalen Status, an dem sich Hinz und Kunz bedienen und beliebig Änderungen vornehmen können? Oder möchtest du mehr Kontrollmöglichkeiten haben und stattdessen getreu dem Prinzip "Don't look for things" auf Dependency Injection setzen und all das übergeben, was die Komponenten für ihre Arbeit brauchen.

Letzteres hat den Vorteil, dass du als Verwender bereits im Konstruktor sehen kannst, was die Klasse benötigt und nicht umhinkommst, diese Voraussetzungen zu erfüllen, bevor du die Klasse verwenden kannst. Wenn die Klasse stattdessen selbständig umherschaut und sich das benötigte Zeug zusammensucht, musst du anderweitig wissen, was du und an welcher Stelle du es bereitzustellen hast, damit die Klasse arbeiten kann.

Nebenfrage: ich habe aus SelfHTML kreisen gehört das es nicht gut sei, Superglobale Variablen zu verwenden. Bei globale Variablen kann ich nur erfahrungsgemäß zustimmen, aber bei einem Superglobalen assoziativem Array wie $SESSION oder $SERVER frage ich mich warum?

Ob global oder superglobal ist in der Hinsicht ob gut oder schlecht kein Unterschied. Das muss im Zuge der obigen Frage geklärt werden.

$_SESSION und $_SERVER und die anderen von PHP bereitgestellten Datenstrukturen haben aber eine Sonderrolle, als dass sie spezielle Informationen enthalten und/oder als Datenspeicher dienen. Als solche sind sie eher mit dem DBMS oder dem Dateisystem zu vergleichen, das auf ähnliche Weise die Aufgabe hat, Daten bereitzustellen und/oder zu speichern.

Da wäre für deine Architektur des Frameworks zu klären: Brauchen deine Komponenten das Wissen, dass solche Datenstrukturen existieren? Oder sollten sie nicht lieber die Daten in allgemeiner Form entgegennehmen, und eine spezielle Komponenten kümmert sich um den eigentlichen Zugiff auf die Datenquelle.

Beispielsweise sollte sowas deiner Geschäftslogik egal sein. Die soll lediglich die Daten gemäß Anforderung verarbeiten. Wo diese herkommen, spielt für sie keine Rolle. Und wenn sich morgen ändert, dass sie woanders gespeichert werden, dann musst du nur den Zugriffsservice ändern oder austauschen, nicht aber durch die gesamte Geschäftlogik durchlaufen und schauen, wo überall ein direkter Zugriff auf die Ressourcen eingebaut ist.

dedlfix.

[Christian Kruse]

Hallo MB,

um Konfigurationen in einem Framework zu setzten, kann man ein Superglobale assoziatives Array verwnden $GLOBALS oder eine Klasse Config::get() - mein Wissensstand.

Es gibt auch eine Menge anderer Methoden. Du kannst auch im Rahmen des Startups ein Objekt erstellen, dass die Konfiguration enthält. Das reichst du dann an deine Controller durch. Das würde ich eh vorschlagen, denn nur so kannst du auch sinnvoll automatisiert testen, globale Werte sind da sehr hinderlich.

Nebenfrage: ich habe aus SelfHTML kreisen gehört das es nicht gut sei, Superglobale Variablen zu verwenden. Bei globale Variablen kann ich nur erfahrungsgemäß zustimmen, aber bei einem Superglobalen assoziativem Array wie $SESSION oder $SERVER frage ich mich warum?

Ich glaube, da hast du etwas falsch verstanden. So pauschal würde das hier glaube ich keiner sagen.

LG,
CK

[pl]

SESSION und SERVER enthalten User-Daten, z.B. Request-Parameter die der Webserver in das Array $_SERVER setzt. Sobald die Response raus ist, darf von Benutzerdaten nichts im Hauptspeicher verbleiben, was $_SESSION und $_SERVER betrifft, da kümmert sich PHP selbst um den Cleanup (destroy).

Eine Config hingegen kann statisch sein, i.d.R. ist die ja beim nächsten Request immer noch dieselbe, kann also im Hauptspeicher verbleiben. Wenn Du mal ein mod_perl oder mod_php oder PHP als FastCGI konfigurieren solltest, ist das sehr zum Vorteil wenn die Config und auch Templates bereits im Hauptspeicher liegen.

Die Templates aber nicht gerendert, weil das ja wieder vom Request, also vom User abhängig ist was da an Daten reinkommt bzw. rausgeht. In meiner Praxis mod_perl wurden Templates auch nicht gleich beim Serverstart in den Hauptspeicher geladen sondern beim ersten Request. MfG

[dedlfix]

Tach!

Sobald die Response raus ist, darf von Benutzerdaten nichts im Hauptspeicher verbleiben, was $_SESSION und $_SERVER betrifft, da kümmert sich PHP selbst um den Cleanup (destroy).

Das betrifft sämtlichen vom Script belegten Speicher.

Eine Config hingegen kann statisch sein, i.d.R. ist die ja beim nächsten Request immer noch dieselbe, kann also im Hauptspeicher verbleiben. Wenn Du mal ein mod_perl oder mod_php oder PHP als FastCGI konfigurieren solltest, ist das sehr zum Vorteil wenn die Config und auch Templates bereits im Hauptspeicher liegen.

Das ist vielleicht bei mod_perl so, aber von PHP überlebt nichts das Script-Ende (Ausnahme Persistente Datenbankverbindungen, wenn mod_php verwendet wird).

In meiner Praxis mod_perl wurden Templates auch nicht gleich beim Serverstart in den Hauptspeicher geladen sondern beim ersten Request.

Das hat nur keine Relevanz für PHP. Da gibts es keine Möglichkeit, vor der Ausführung von Scripts bereits etwas Globales zu starten.

dedlfix.

[Mitleser]

Die Templates aber nicht gerendert, weil das ja wieder vom Request, also vom User abhängig ist was da an Daten reinkommt bzw. rausgeht. In meiner Praxis mod_perl wurden Templates auch nicht gleich beim Serverstart in den Hauptspeicher geladen sondern beim ersten Request.

Dann verschenkst Du aber einiges an Potential. Wenn Du mit mod_perl und HTML::Template::Compiled arbeiten würdest, könntest Du die Templates beim Serverstart kompiliert im Shared Memory halten. Immenser Vorteil.