Ich entwickle gerade eine objektorientierte PHP-Website und versuche herauszufinden, wie man die Datenbankfunktionalität am besten vom Rest des Systems abstrahieren kann. Im Moment habe ich eine DB-Klasse, die alle Verbindungen und Abfragen verwaltet, die das System verwendet (es ist eine Schnittstelle zu MDB2). Bei der Verwendung dieses Systems habe ich jedoch festgestellt, dass viele SQL-Abfragezeichenfolgen überall in meinem Code auftauchen. Zum Beispiel habe ich in meiner Benutzerklasse so etwas:
%Vor%Was ich gerne machen würde, ist herauszufinden, wie man die Menge an Inline-SQL am besten reduziert. Ich verstehe, dass eine Möglichkeit, das zu tun, darin besteht, Funktionen innerhalb des Benutzers für jede der Abfragen zu schreiben, die der Benutzer benutzt (etwas wie das Folgende), aber das könnte zu einigen Funktionen führen.
%Vor%Also ... meine Frage. Was ist die beste Technik zum Verwalten der großen Anzahl von Abfragen, die eine typische Datenbankanwendung verwenden würde? Wäre der von mir beschriebene Weg der richtige Weg, um mit dieser Situation umzugehen? Oder wie wäre es mit der Registrierung einer Liste von Abfragen in der DB-Klasse und dem Zuordnen einer eindeutigen ID (z. B. USER_CHECKLOGIN), die an die Abfragefunktion der Datenbank übergeben wird? Diese Methode könnte auch bei der Sicherheit helfen, da sie die Abfragen beschränken würde, die nur für diejenigen ausgeführt werden können, die in dieser Liste registriert sind, aber es ist eine weitere Sache, die Sie beim Schreiben aller Klassenfunktionen beachten sollten. Gedanken?
Das SQL in einzelne Funktionen zu ziehen ist ein guter Anfang. Einige andere Dinge, die Sie tun können:
Vielleicht möchten Sie sich die Implementierung des ActiveRecord-Patterns ansehen. Durch die Verwendung eines Entwurfsmusters erhalten Sie eine gewisse Konsistenz bei der Arbeit mit Daten aus Ihren Tabellen. Es kann einige Nachteile für diese Art von Ansätzen geben, hauptsächlich die Leistung für bestimmte Arten von Abfragen, aber es kann umgangen werden.
Eine andere Möglichkeit kann die Verwendung eines ORM sein, für PHP die mächtigsten:
Beide ermöglichen Ihnen den Zugriff auf Ihre Datenbank mit einer Reihe von Objekten und bieten eine einfache API zum Speichern und Abfragen von Daten. Beide haben ihre eigene Abfragesprache, die intern in das zielgerichtete native SQL-DBMS konvertiert wird, wodurch die Migration von Anwendungen erleichtert wird ein RDBMS zu einem anderen mit einfachen Konfigurationsänderungen. Ich mag auch die Tatsache, dass Sie die Datamodell-Logik kapseln können, um beispielsweise eine Validierung hinzuzufügen, indem Sie nur Ihre Modellklassen erweitern.
Da Sie sagen, dass Sie das als OO PHP machen, warum haben Sie SQL dann durch alle Methoden gestreut? Häufigere Modelle wären:
Die erste Option wird in der Regel robuster sein, aber die zweite Option wird möglicherweise schneller ausgeführt und wird sich wahrscheinlich vertrauter anfühlen, als Sie es gewohnt sind, Dinge zu tun, wenn beides eine Rolle spielt.
Für Ihr Login-Beispiel würde ich es dann so tun, als würde ich den Benutzer einfach per E-Mail-Adresse laden, $user->check_password($entered_password) aufrufen und eine Ausnahme auslösen / return false / was auch immer, wenn check_password fehlschlägt. Weder check_password noch ein anderer Code zur Verarbeitung von Anmeldedaten müssen sich mit der Datenbank befassen oder sogar wissen, dass der Benutzer aus einer Datenbank geladen wird.
Eine weitere Option besteht darin, die Abfragen als Daten zu betrachten und sie in der Datenbank zu speichern. Sie können beispielsweise eine Tabelle erstellen, in der die Abfrage mit einem Namen gespeichert wird, und eine andere Tabelle, in der die Parameter für diese Abfrage gespeichert sind. Dann erstellen Sie eine Funktion in PHP, die den Namen der Abfrage und ein Array von Parametern übernimmt und die Abfrage ausführt, wobei alle Ergebnisse zurückgegeben werden. Sie können den Abfragen auch andere Metadaten hinzufügen, um den Zugriff auf bestimmte Benutzer zu beschränken, Post-Funktionen auf die Ergebnisse anzuwenden usw.