nicht angemeldet
Konfigurationsdaten Projekt
Hi, ich fange wieder mal ein neues Projekt an, und möchte mal neue Wege gehen.
Früher hatte ich immer alle Konfigurationswerte als Konstanten definiert. Diesmal möchte ich das anders machen.
Was ist denn so der Stand der Dinge? Alle Konfig-Daten in einer XML-Datei abzulegen und per setter an die entsprechenden Methoden weiterzureichen? Völliger Verzicht auf Konstanten?
Ich hatte nämlich damals immer das Problem, dass ich die Konstanten dann direkt in den Klassen verwendet hatte, z.b. als Default. Das möchte ich aber ab jetzt vermeiden, ich denke, das ist kein guter Stil. Was sagt ihr dazu?
für ein paar UpToDate-Tips wäre ich dankbar
grüße
PM
-
Hallo!
für ein paar UpToDate-Tips wäre ich dankbar
Konstanten sind wirklich nicht das gelbe vom Ei.
Ich persönlich verwende für jede Controller-Klasse eine eigene Config-Klasse.Grüße, Matze
-
Hi,
für ein paar UpToDate-Tips wäre ich dankbar
Konstanten sind wirklich nicht das gelbe vom Ei.
Ich persönlich verwende für jede Controller-Klasse eine eigene Config-Klasse.und wie hinterlegst du die Konfig-daten? Array? Objektvariablen? Json? XML? Ini-Datei?
-
und wie hinterlegst du die Konfig-daten? Array? Objektvariablen? Json? XML? Ini-Datei?
Ein Cache-Array und die magischen Funktionen als getter und setter dazu.
Grüße, Matze
-
Moin!
Hi,
für ein paar UpToDate-Tips wäre ich dankbar
Konstanten sind wirklich nicht das gelbe vom Ei.
Ich persönlich verwende für jede Controller-Klasse eine eigene Config-Klasse.und wie hinterlegst du die Konfig-daten? Array? Objektvariablen? Json? XML? Ini-Datei?
Konfiguration sollte performantest gelesen werden können. Das schließt alles aus, was nicht originär PHP-Code (der aus dem Opcode-Cache gelesen werden kann) ist.
Wenn also XML, INI oder JSON als Speicherformat erforderlich ist, möchte man sich an dieser Stelle einen Zwischenspeicher einbauen, der ein PHP-Array als PHP-Code-Includefile abspeichert.
- Sven Rautenberg
-
-
-
Hi, ich fange wieder mal ein neues Projekt an, und möchte mal neue Wege gehen.
Früher hatte ich immer alle Konfigurationswerte als Konstanten definiert. Diesmal möchte ich das anders machen.Welche Konfiguration? Es gibt so viele verschiedene Dinge:
- Konfiguration auf bzw. der Server-Ebene
- Konfiguration der Applikation
- Konfiguration von Einzelteilen, die in der Applikation benutzt werden.
Was ist denn so der Stand der Dinge? Alle Konfig-Daten in einer XML-Datei abzulegen und per setter an die entsprechenden Methoden weiterzureichen? Völliger Verzicht auf Konstanten?
Keine Konfigurationswerte haben. Die machen nämlich das Testen komplizierter, weil z.B. pro binärem Wert zwei Testfälle entstehen: Eingeschaltet und ausgeschaltet muss es funktionieren. Bei zweier solcher Schalter sind es schon vier Testfälle.
XML zu haben macht Konfigurationswerte nicht besser.
Was ist an Konstanten schlecht? Die sind ideal, um die Autocompletion der IDE zu nutzen, und um die möglichen Werte einer Konfiguration aufzunehmen.
Wie kommt die Konfiguration irgendwohin? Indem sie dem Konstruktor des relevanten Objekts bei dessen Erstellung mitgegeben wird. Keinesfalls werden solche Werte durch mehrere Objekte durchgereicht!
Wenn tatsächlich Werte erst zur Laufzeit der Applikation entstehen und irgendwohin gelangen müssen, sind das keine Konfigurationswerte. Konfigurationswerte stehen vor dem Start der Applikation fest und ändern sich während der Lebenszeit nicht.
- Sven Rautenberg
-
Hallo!
Was ist an Konstanten schlecht?
Ihr Speicherverbrauch.
Die sind ideal, um die Autocompletion der IDE zu nutzen, und um die möglichen Werte einer Konfiguration aufzunehmen.
Das geht auch mit Klassen.
Wie kommt die Konfiguration irgendwohin? Indem sie dem Konstruktor des relevanten Objekts bei dessen Erstellung mitgegeben wird. Keinesfalls werden solche Werte durch mehrere Objekte durchgereicht!
Was hast du gegen statische Objekte?
Wenn tatsächlich Werte erst zur Laufzeit der Applikation entstehen und irgendwohin gelangen müssen, sind das keine Konfigurationswerte. Konfigurationswerte stehen vor dem Start der Applikation fest und ändern sich während der Lebenszeit nicht.
Wie denkst du dabei über Servereinsetllungen die ich mit PHP erst zur Laufzeit auslesen und auswerten kann?
Grüße, Matze
-
Tach!
Was ist an Konstanten schlecht?
Ihr Speicherverbrauch.Wieviel Tonnen davon willst du denn erzeugen, dass das eine Auswirkung hat? Zusatzfrage: Um wieviel Byte/Prozent reden wir eigentlich?
Wie kommt die Konfiguration irgendwohin? Indem sie dem Konstruktor des relevanten Objekts bei dessen Erstellung mitgegeben wird. Keinesfalls werden solche Werte durch mehrere Objekte durchgereicht!
Was hast du gegen statische Objekte?Prinzipiell sicher nichts, aber du gedenkst drauf von anderenorts zuzugreifen, statt die Werte daraus zu übergeben. Das wäre Global State, den es nach den Clean-Code-Richtlinien zu vermeiden gilt. - Das ist kein Gesetz, nur eine Richtlinie, an die man sich halten kann, wenn sie einen überzeugt, oder auch nicht.
Wenn tatsächlich Werte erst zur Laufzeit der Applikation entstehen und irgendwohin gelangen müssen, sind das keine Konfigurationswerte. Konfigurationswerte stehen vor dem Start der Applikation fest und ändern sich während der Lebenszeit nicht.
Wie denkst du dabei über Servereinsetllungen die ich mit PHP erst zur Laufzeit auslesen und auswerten kann?
Oder wie bringst du den User-Agent-String in Konfigurationen unter?Gar nicht. Das sind zu verarbeitende Daten, genauso wie $_POST und Konsorten.
dedlfix.
-
Hallo!
Wieviel Tonnen davon willst du denn erzeugen, dass das eine Auswirkung hat? Zusatzfrage: Um wieviel Byte/Prozent reden wir eigentlich?
Gegenfrage: Ab wann ist wenig nicht mehr wenig? Afaik(!) wird bei jedem Aufruf einer globalen Variable intern eine Kopie erstellt. Verwende ich ein Objekt, benutze ich intern Pointer. Vielleicht weiß da jemand genaueres dazu, das ist zumindest was ich irgendwoher im Hinterkopf habe. Wobei ich da auch gerade selbst zweifle weil ich keine Quelle zu so einer Aussage finden kann. Vielleicht bin ich da tatsächlich einfach auf dem falschen Weg.
Prinzipiell sicher nichts, aber du gedenkst drauf von anderenorts zuzugreifen, statt die Werte daraus zu übergeben. Das wäre Global State, den es nach den Clean-Code-Richtlinien zu vermeiden gilt. - Das ist kein Gesetz, nur eine Richtlinie, an die man sich halten kann, wenn sie einen überzeugt, oder auch nicht.
Das kannst du auch umgehen indem du dem Ganzen eine statische getter-Funktion verpasst.
Das sind zu verarbeitende Daten, genauso wie $_POST und Konsorten.
Nein, ich hatte die Aussage einfach nur falsch verstanden.
Sven schrieb:
Werte [die] erst zur Laufzeit der Applikation entstehen
ich machte daraus:
[..]einsetllungen die ich [..] erst zur Laufzeit auslesen und auswerten kann
Da hat mich was ganz anderes geritten. :/
Grüße, Matze
-
Tach!
Wieviel Tonnen davon willst du denn erzeugen, dass das eine Auswirkung hat? Zusatzfrage: Um wieviel Byte/Prozent reden wir eigentlich?
Gegenfrage: Ab wann ist wenig nicht mehr wenig? Afaik(!) wird bei jedem Aufruf einer globalen Variable intern eine Kopie erstellt. Verwende ich ein Objekt, benutze ich intern Pointer.Es ging um Konstanten, nicht um Variablen.
Vielleicht weiß da jemand genaueres dazu, das ist zumindest was ich irgendwoher im Hinterkopf habe. Wobei ich da auch gerade selbst zweifle weil ich keine Quelle zu so einer Aussage finden kann. Vielleicht bin ich da tatsächlich einfach auf dem falschen Weg.
Selbst bei Variablen fällt bei einer Übergabe als Kopie nicht mehr Aufwand an, als bei einer Übergabe per Referenz. Eine Variable wird erst dann richtig kopiert, wenn sich ihr Inhalt von dem ihrer Quelle zu unterscheiden beginnt. Solange sieht sie intern fast wie eine Referenz aus. Copy-On-Write nennt sich das. Siehe jenes PDF-Dokument: References in PHP (ist schon etwas älter, aber vermutlich immer noch gültig).
Prinzipiell sicher nichts, aber du gedenkst drauf von anderenorts zuzugreifen, statt die Werte daraus zu übergeben. Das wäre Global State, den es nach den Clean-Code-Richtlinien zu vermeiden gilt. - Das ist kein Gesetz, nur eine Richtlinie, an die man sich halten kann, wenn sie einen überzeugt, oder auch nicht.
Das kannst du auch umgehen indem du dem Ganzen eine statische getter-Funktion verpasst.Ich muss mich erstmal korrigieren. Es war nicht Global State sondern Don't look for Things.
Eine statische Getter-Funktion ist (nach Don't-look-for-Things-Gesichtspunkten) nicht besser als der Zugriff auf eine statische Klassen-Variable oder -Konstante oder auch Konstanten allgemein und globale Variablen. In allen Fällen greifst du auf etwas zu, das außerhalb der Klasse existieren muss, statt ihr etwas zu übergeben, was man im Test-Fall auch mal faken kann.
dedlfix.
-
Hallo!
Es ging um Konstanten, nicht um Variablen.
Gott was hab ich mich hier verzettelt...
Ich klink mich berechtigter Weise mal wieder aus dem thread aus und geh mich eine Runde schämen.
Grüße, Matze
-
Tach!
Ich klink mich berechtigter Weise mal wieder aus dem thread aus und geh mich eine Runde schämen.
Achwas, geh dir lieber die Clean-Code-Videos anschauen.
dedlfix.
-
Hallo!
Achwas, geh dir lieber die Clean-Code-Videos anschauen.
Was meinst du? Sorry, ich steh auf dem Schlauch.
Grüße, Matze
-
Tach!
Achwas, geh dir lieber die Clean-Code-Videos anschauen.
Was meinst du? Sorry, ich steh auf dem Schlauch.Ich meinte, du solltest deine Zeit nicht mit Schämen vergeuden sondern lieber etwas sinnvolles tun, zum Beispiel die bereits erwähnten Clean-Code-Talks-Videos anschauen.
dedlfix.
-
-
-
-
-
-
-
-
Wenn tatsächlich Werte erst zur Laufzeit der Applikation entstehen und irgendwohin gelangen müssen, sind das keine Konfigurationswerte. Konfigurationswerte stehen vor dem Start der Applikation fest und ändern sich während der Lebenszeit nicht.
Wie denkst du dabei über Servereinsetllungen die ich mit PHP erst zur Laufzeit auslesen und auswerten kann?
Oder wie bringst du den User-Agent-String in Konfigurationen unter?
Grüße, Matze