Ich komme also nicht von einem riesigen PHP-Hintergrund - und ich frage mich, ob man in gut ausgeformtem Code die "Superglobals" direkt verwenden sollte, z. in der Mitte einer Funktion sagen $_SESSION['x'] = 'y'; oder wenn, wie ich normalerweise mit Variablen tun würde, ist es besser, sie als Argumente zu senden, die von dort verwendet werden können, zum Beispiel:
und dann die Doer->sess Version von Doer und so. (Der Vorteil dieser Methode ist, dass%% s% verwendet $ _SESSION.)
Was ist der akzeptierte PHP-Designansatz für dieses Problem?
Ich möchte $_SESSION , $_POST , $_GET und $_COOKIE in OOP-Strukturen einschließen.
Ich verwende diese Methode, um Code zu zentralisieren, der Sanitation und Validierung, alle notwendigen isset () checks, nonces, setcookie -Parameter usw. behandelt. Er ermöglicht auch Client-Code lesbarer zu sein (und gibt mir die Illusion, dass es ist wartbarer).
Es kann schwierig sein, die Verwendung dieser Art von Struktur zu erzwingen, besonders wenn es mehrere Codierer gibt. Mit $_GET , $_POST und $_COOKIE (glaube ich) kann Ihr Initialisierungscode die Daten kopieren und dann den Superglobal zerstören. Vielleicht könnte ein cleverer Destruktor dies mit $ _SESSION (wipe $ _SESSION beim Laden, schreiben Sie es zurück in den Destruktor) machen, obwohl ich es nicht versucht habe.
Normalerweise verwende ich jedoch keine dieser Techniken zur Durchsetzung. Nachdem ich mich daran gewöhnt habe, sieht $_SESSION im Code außerhalb der Session-Klasse einfach komisch aus und ich arbeite meistens alleine.
BEARBEITEN
Hier ist ein Beispiel für einen Client-Code, falls er jemandem hilft. Ich bin mir sicher, dass das Betrachten eines der wichtigsten Frameworks Ihnen bessere Ideen geben würde ...
Post und seine Freunde stammen alle von einer Basisklasse ab, die den Kernvalidierungscode implementiert und ihre eigenen spezifischen Funktionen wie Formulartokens, Session-Cookie-Konfiguration, was auch immer hinzufügt.
Intern enthält die Klasse eine Sammlung gültiger Daten, die beim Aufruf der Validierungsmethoden aus $_POST extrahiert werden. Anschließend werden sie als Eigenschaften mithilfe einer magischen __get -Methode zurückgegeben. Fehlgeschlagene Felder können nicht auf diese Weise erreicht werden. Meine Validierungsmethoden (außer required ) schlagen bei leeren Feldern nicht fehl, und viele von ihnen verwenden func_get_args , um ihnen zu erlauben, auf mehreren Feldern gleichzeitig zu operieren. Einige der Methoden (wie money ) übersetzen die Daten automatisch in benutzerdefinierte Werttypen.
Im Fehlerfall habe ich eine Möglichkeit, die Daten in ein Format umzuwandeln, das in der Sitzung gespeichert und zum Vorfüllen des Formulars und zum Hervorheben von Fehlern nach dem Umleiten in das ursprüngliche Formular verwendet werden kann.
Eine Möglichkeit, dies zu verbessern, wäre das Speichern der Validierungsinformationen in einer Form-Klasse, die zum Rendern der Formular- und Power-Client-Validierung sowie zum Bereinigen der Daten nach der Übergabe verwendet wird.
Das Ändern der Inhalte der Superglobals wird als schlechte Übung betrachtet. Es ist zwar nichts wirklich falsch, besonders wenn der Code zu 100% unter Ihrer Kontrolle steht, es kann jedoch zu unerwarteten Nebeneffekten führen, besonders wenn Sie Mixed-Source-Code in Betracht ziehen. Zum Beispiel, wenn Sie so etwas tun:
%Vor% Sie könnten erwarten, dass überall, wo PHP das "someval" zur Verfügung stellt, auch Änderungen vorgenommen werden, aber das ist nicht der Fall. Die Kopie in $_REQUEST['someval'] bleibt unverändert und ist immer noch die ursprüngliche "unsichere" Version. Dies könnte zu einer unbeabsichtigten Injektionsanfälligkeit führen, wenn Sie alle Ihre Escapes auf $ _POST ausführen, aber eine spätere Bibliothek verwendet $ _REQUEST und geht davon aus, dass sie bereits maskiert wurde.
Auch wenn Sie sie modifizieren können, ist es am besten, die Superglobals als schreibgeschützt zu behandeln. Wenn Sie sich mit den Werten herumschlagen müssen, pflegen Sie Ihre eigenen parallelen Kopien und machen Sie alle Wrapper / Zugriffsmethoden, die für die Pflege dieser Kopie erforderlich sind.
Ich weiß, dass diese Frage alt ist, aber ich möchte eine Antwort hinzufügen.
Mario's Klassen, um die Eingaben zu handhaben, sind großartig.
Ich bevorzuge es, die Superglobale irgendwie zu verpacken. Es kann Ihren Code VIEL einfacher zu lesen und zu einer besseren Wartbarkeit führen.
Zum Beispiel gibt es in meinem aktuellen Job Code, den ich hasse! Die Sitzungsvariablen werden so stark verwendet, dass Sie die Implementierung nicht realistisch ändern können, ohne die gesamte Site drastisch zu beeinflussen.
Zum Beispiel
Nehmen wir an, Sie haben eine für Ihre Anwendung spezifische Session-Klasse erstellt.
%Vor%Sie könnten etwas wie das Folgende schreiben
%Vor%Im Gegensatz dazu
%Vor%Das klingt ein bisschen trivial, aber es ist eine große Sache für mich. Sag, dass ich irgendwann in der Zukunft entscheiden werde, dass ich den Namen des Index von "geloggt" zu "gelogged" ändern möchte.
Ich muss jetzt an jeden Ort in der App gehen, an dem die Session-Variable verwendet wird, um dies zu ändern. Oder ich kann es verlassen und eine Möglichkeit finden, beide Variablen beizubehalten.
Oder was, wenn ich überprüfen möchte, dass dieser Benutzer ein Administrator ist und angemeldet ist? Ich könnte am Ende zwei verschiedene Variablen in der Sitzung überprüfen. Aber stattdessen könnte ich es in eine Methode einkapseln und meinen Code verkürzen.
Dies hilft anderen Programmierern, sich Ihren Code anzusehen, weil er einfacher zu lesen ist und nicht so viel darüber "nachdenken" muss, wenn er sich den Code anschaut. Sie können zur Methode gehen und sehen, dass es nur EINE Möglichkeit gibt, einen angemeldeten Benutzer zu haben. Es hilft Ihnen auch, denn wenn Sie den 'eingeloggten' Check komplexer machen möchten, müssen Sie nur an einen Ort gehen, um ihn zu ändern, anstatt zu versuchen, globale Funde mit Ihrer IDE zu machen und zu versuchen, sie so zu ändern.
Auch dies ist ein triviales Beispiel, aber abhängig davon, wie Sie die Sitzung verwenden, könnte dieser Weg, Methoden und Klassen zum Schutz des Zugriffs zu verwenden, Ihr Leben viel einfacher machen.
Ich würde nicht empfehlen, Superglobal als Referenz zu übergeben. In Ihrer Klasse ist es unklar, dass das, was Sie ändern, eine Sitzungsvariable ist. Beachten Sie auch, dass $ _SESSION überall außerhalb Ihrer Klasse verfügbar ist. Aus objektorientierter Sicht ist es so falsch, in der Lage zu sein, eine Variable innerhalb einer Klasse von außerhalb dieser Klasse zu modifizieren, indem eine Variable modifiziert wird, die nicht mit der Klasse verwandt ist. Öffentliche Attribute zu haben ist eine schlechte Praxis, das ist sogar schlimmsten.
Tags und Links php global-variables superglobals