PHP: MVC-Benutzer-Authentifizierung und globales user-Objekt?
Schreibe ich meine erste richtige MVC-Anwendung mit PHP. Ich bin nicht mit einem framework, da meine Anwendung ist so klein, dass ich dachte, es wäre schneller zu schreiben alles von Grund auf.
In meiner app, Benutzer können registrieren, einloggen und dann schreiben/Bearbeiten/löschen von Inhalten. Jedes Stück der Inhalte, Verweise seinem Besitzer mit einer Benutzer-id-Spalte in der Datenbank.
Ich bin jetzt zu implementieren, Benutzer-Zugriffsbeschränkungen (in dem Sinne, dass Benutzer können nur anzeigen/Bearbeiten/löschen Ihre EIGENEN Inhalte/Produkte/Modelle). Ich Frage mich, wo die Prüfung für "valid access" geschehen soll und wo die user-Objekte werden instanziiert.
Ich meine, ich auf jeden Fall brauchen Informationen über den aktuellen Benutzer in den Controller, Modelle und views. Also ich denke, wenn es sinnvoll ein globales user-Objekt (definiert in index.php), die speichert alle Benutzer-Informationen, so konnte ich darauf zugreifen, bequem von jedem Teil meiner Bewerbung.
Im moment, dieses snippet gewährt mein-Controller Zugriff auf Benutzer-Informationen, die ich dann auch speichern in der Daten-array übergeben wird, zu der Ansicht:
class Controller {
protected $data, $id, $user;
public function __construct($action = null, $data = null) {
if (User::isLoggedIn()) {
$this->user = new User($_SESSION['user']);
$this->data['user'] = $this->user;
}
}
}
Folgenden dieses Muster, ich würde zu Durchlaufen haben, auf die Benutzer Informationen zu jedem Modell, das ich erstellen, oder alternativ haben Sie instanziieren Sie Ihre eigenen Benutzer-Objekt.
Was ist der Weg, hier zu gehen? Globale Benutzer-Objekt-Instantiierung in jedem Modell, oder der übergabe der Benutzer-Objekt als parameter an Modelle und Ansichten?
Danke für Eure Hilfe!
- Über ACL finden Sie vielleicht dieser Beitrag interessant: stackoverflow.com/questions/3430181/acl-implementation/...
- Hey PeeHaa! Danke für den link. Das war auf jeden Fall eine interessante Lektüre, obwohl ich nicht wollen, zu bekommen, dass komplexe. Jetzt weiß ich, dass "ACL" ist der Begriff, den ich Suche. Vielleicht, was ich tun werde, ist bauen eine ACL-Klasse und nicht mit einer globalen Benutzer-Objekt (aber instanziieren es in beiden model-und controller-und, wenn nötig). Ich bin immer noch nicht ganz sicher, aber wenn mein Modell benötigt Zugriff auf die ACL oder wenn ich es Schaffe alle Benutzer Zugriff von meinem controller.
- Globals schlecht. Dependency Injection gut. Eng gekoppelte code kann einfacher sein, zu schreiben, aber es ist schwieriger zu pflegen. Lose gekoppelten code ist schwieriger zu schreiben und zu konzipieren, aber erstaunlich einfacher, mit zu arbeiten auf lange Sicht. (Bonus-Punkte, wenn Sie den Namen des prähistorischen internet-meme, die ich gerade heraufbeschworen.)
- Hey Charles! Vielen Dank für Ihren Kommentar. Ich bin damit einverstanden. Ich bin mir ziemlich sicher, dass dein Kommentar war gerichtet auf die Betrachtung der globalen Benutzer-Objekt. Ich werde auf jeden Fall nicht so. Allerdings bin ich mir noch nicht ganz sicher, ob mein Modell benötigt Zugriff auf die ACL oder wenn ich es Schaffe alle Benutzer Zugriff von meinem controller.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gibt es einige Dinge zu beachten. Erstens: "ich habe dann auch speichern in der Daten-array übergeben wird, zu der Ansicht:"
In MVC die view hat einen direkten Zugang zum Modell, siehe meine Antwort hier Wie ist MVC eigentlich Arbeit in CodeIgniter für einen überblick über, die.
Zweitens, deine Frage ist wirklich über das Dependency Management. Globals (und durch die Erweiterung Statik) sind problematisch ( Alle Variablen global, PHP , Sind das Globale Variablen schlecht? , Statische Methoden oder nicht? ). Die bevorzugte Methode ist die übergabe der voll-gebaut $user-Objekt in der Klasse, die es erfordert.
Jedoch, in diesem Fall können Sie nicht eine voll-konstruiert user-Objekt, denn Sie müssen wissen, ob der Benutzer eingeloggt ist vor der Konstruktion das Objekt so übergeben Sie einen mapper, Werk-oder DAO-Objekt in den Konstruktor, und erstellen Sie den Benutzer erforderlich.
Schließlich, jedoch, wenn Sie meinen ersten Punkt, dass sich die Ansichten können auf Ihr Modell direkt und nicht get übergebenen Daten, indem Sie Ihre controller, dann ist dein controller vielleicht nicht einmal wissen müssen, ob der Benutzer angemeldet ist. Das ist, nach allem, domain-Logik, so gehört in das Modell.