Komplettes Projekt in OOP

[Chris]

Mit anderen Worten, sie enthalten Statementerstellung. Das würde Aufgabe einer eigenständigen Klasse sein. Dummerweise braucht man für mysqli::real_escape_string() eine geöffnete Verbindung (und mysqli::set_charset() muss auch ausgeführt sein). Die kannst du dir in deinem Fall über das Singleton holen. Die Statement-Klasse muss man auch mehrfach aufrufen können, um unterschiedliche Statements zu erzeugen. Sie muss also "ganz normal" bleiben.

Gut damit steht fest das die DBKlasse Singleton wird. Die Statementklasse werde ich aber auch immer brauchen. Wie also mache ich es damit? das Objekt _immer_ per Parameter übergeben? Schließlich wird es kaum eine Klasse geben ohne Datenbankaktivität. Und hier bin ich schon wieder bei der Ausgangsfrage[[1].

Hier fehlt die kontextgerechte Behandlung der Strings. Ein O'Brien macht dir nur einen Syntaxfehler. Ein gezieltes Ausnutzen dieser SQL-Injection-Lücke gefährdet deinen Datenbestand.

Nein da es eine Klasse geben wird bzw. eine Funktion die alle $_Requests behandelt nach Magic Quotes. Zumindestens habe ich das so vor. hm...

Auch der Tabellenname erfordert eine kontextgerechte Behandlung, wenn du ihn als einen variablen Bestandteil einfügst. Dafür gibt es aber keine vorgefertigte Funktion, du müsstest dir eine gemäß den Regeln für Identifier selbst erstellen.

S.o.

Schau dir mal die Funktion sprintf() an. Mit der bekommst du die Stringerstellung (meiner Meinung nach) übersichtlicher hin.

Jap die kenne ich, habe ich leider garnicht dran gedacht. Danke.

Zum Erstellen eines mysqli_stmt-Objekts benötigst du ein mysqli-Objekt. Wenn du also noch kein mysqli_stmt-Objekt hast, würde diese Funktion besser in die Basisklasse passen. Als Ergebnis solltest du entweder ein Objekt einer Result-Klasse oder eine andere Datenstuktur bekommen.

Wenn du sowieso die Statements erst noch zusammenbauen lässt, ist das Verwenden von Prepared Statements nicht sehr sinnvoll. Das Handling ist deutlich aufwendiger als das Statement auf herkömmliche Weise (inklusive Maskierung und Quotierung) zu erstellen, mysql::query() aufzurufen und das Ergebnis abzuholen.

Hm also wäre es besser die Statements nicht dynamisch zu erzeugen sondern wie sonst auch. Auf prepared Statements möchte ich nicht verzichten.

»» ################# db_count_found_or_affected_rows
»» ################# db_fetch_object
»» ################# db_free_result

Das ist Bestandteil des Ergebnismengenhandlings. Es ist sinnvoll, das vom Statement zu trennen, denn ein Statement kann mehrere Resultsets liefern (auch wenn du solche Statements wahrscheinlich nicht verwenden wirst).

Sprich ich packe das was mit dem RESULT gemacht werden soll in eine extra Klasse? Und diese muss ich auch wieder jeder Klasse mitgeben die mit Datenbank kommuniziert..was mich zu Problem [1] bringt.

»» ################# db_close

Keiner deiner DB-Objekt-Verwender kann wissen, wann die Verbindung geschlossen werden kann. Wenn überhaupt, kann nur der Destruktor die Verbindung schließen oder der Automatismus am Scriptende.

Also entweder weglassen oder die Funktion im Destruktor aufrufen.

»» » »» Die MainKlasse wird wieder als Singleton P. gemacht
»» » Was ist die Aufgabe der MainKlasse?
»» Hier sind so "Standard"-Funktionen drin. Ich nenne mal Beispiele:
»» function check_arrays(}
»» function get_all_requests_in_array(){}

Das soll also eigentlich eine Tools/Utility/Helper-Klasse werden. Die Methoden scheinen mir eigenständig arbeiten zu können, sind also nur in den Klassenrahmen gehängte Funktionen. Dann brauchst du keine Instanz und kein Singleton sondern kannst die Methoden als statisch deklarieren.

Ach wenn ich sie als statisch deklariere kann ich immer auf sie zugreifen? Da hab ich wohl irgendwas beim lernen übersehen. Also sind sie dadurch auch global oder wie läuft das ab weil sie werden ja nicht eingebunden(extends / Parameter).

»» » Das database-Objekt wird ja durch das Singleton Pattern in dem Moment erstellt, wenn der erste Zugriff darauf erfolgt. Ein anderweitiges Anlegen ist weder sinnvoll noch nötig und widerspricht auch dem Singleton Pattern, das verlangt, dass der Konstruktor nicht anderweitig aufgerufen werden darf, also private zu sein hat. Die einzige Möglichkeit an ein "gesingletontes" Objekt zu kommen ist der Aufruf der statischen getInstance-Methode (oder wie auch immer man sie nennt). Und jeder, der das Objekt braucht, holt es sich selbst durch Aufruf dieser Methode. Es muss also nicht noch irgendwo anders (global) abgelegt werden.

Gut - verstanden.

»» Achso okay also spart man sich das "$object = new Classname;"

Es geht nicht nur um das Sparen sondern um das Unmöglichmachen einer direkten Instantiierung. Sonst kann ja jeder kommen und sich Instanzen erstellen, was das Singleton ad absurdum führte.

Achso.

Ja, aber du kannst ja mal da reinschauen und die Erfahrung die dort drinsteckt in dein Wissen aufzunehmen versuchen.

Du hast Recht das werde ich tun.
Hoffe du hilfst mir weiterhin.
Vielen Dank.

Gruß,

Chris