Datenbank Handler richtig einsetzen

Hi leute ich bin nun ein wenig verwirrt:D es geht um folgendes

ich habe einen DataBase handler geschrieben, welcher mir sql injections "neutralisiert". bis jetzt habe ich es immer so verwendet:

class sowieso{

public function sowieso{

$db = new DataBase();

$db->sql("SELECT * FROM sowieso");

bei viele klassen muss ich in jeder funktion dann eine neue instanz anlegen. ich habe mir dann mal überlegt das datenbank objekt an eine private variable zu übergeben und dann immer die variable in der jewaligen klasse benutzen also zb:

class sowieso{

private $db;

public function __construct()

$this->db = new DataBase();

public function sowieso{

$this->db->query("SELECT * FROM sowieso");

nun dachte ich mir $this->db->query... also ist doch alles ganz schön lang und wird unübersichtlich und habe dann folgendes getan:

class sowieso extends DataBase{

public function sowieso{

$this->sql("SELECT * FROM sowieso");

nun meine Frage, soll ich das vererben von DataBase lassen? und/oder das übergeben der datenbank objekts and eine private variable auch lassen? besser in jeder funktion eine neue instanz der datenbank klasse erstellen?

MFG

Das wird oft über ein Singleton gelöst. Dabei benutzt du eine statische Zugriffsmethode und gewährleistest, dass immer nur genau eine Instanz existiert. Singletons allgemein sind etwas umstritten weil sie dazu tendieren, das OOP-Äquivalent globaler Variablen zu sein. Schau dir einfach mal die Theorie dazu an und wäge ab, ob dir das passt.

Von der Idee dass alle Klassen, welche Datenbankzugriff erfordern von deinem Handler extenden halte ich im übrigen garnichts. Egal was du tust - das lässt du bitte bleiben ;)

Warum willst du die Instanz der Datenbank innerhalb der Klasse haben? Ist die Klasse denn eine Spezialisierung der Datenbankklasse? Wenn nicht ist eine Vererbung eher schlecht und das Ganze nur um ein paar Buchstaben einzusparen finde ich dann eine eher fragwürdige Idee.

Wie wäre es denn mit einer Datenbankklasse die das Singleton Pattern umsetzt? Wäre dann in etwa so:

PHP:

class Database
{
   private static $instance = null;
   private __construct() { ... }
   private __clone() {}
   public static function getInstance()
   {
      if(!isset(self::$instance)) {
         self::$instance = new Database();
      }
      return self::$instance;
   }
   public function sql(...)
   {
      ...
   }
}
class sowieso
{
   public function sowieso()
   {
      Database::getInstance()->sql("...");
   }
}

Original von Fobby

Das wird oft über ein Singleton gelöst. Dabei benutzt du eine statische Zugriffsmethode und gewährleistest, dass immer nur genau eine Instanz existiert. Singletons allgemein sind etwas umstritten weil sie dazu tendieren, das OOP-Äquivalent globaler Variablen zu sein. Schau dir einfach mal die Theorie dazu an und wäge ab, ob dir das passt.

Gebe ich dir recht, aber gibts dafür sinnvolle Alternativen? ;) Immerhin will man ja manche Dinge global haben (Logging, Datenbank, Einstellungen usw.). Singleton finde ich da am elegantesten, da man hier den Zugriff auf die Funktionalitäten und Daten komplett kapseln und absichern kann. Globale Variablen kann man ja überschreiben (ob absichtlich oder nicht, auf jeden Fall ist es ärgerlich sowas zu suchen... :))

hm.. prima das mit dem singleton hat wunderbar funktioniert muss jetzt nur noch überall die alten instanzen der db löschen, danke euch(von wegen man kann hier nichts lernen)

MFG

EDIT: habe gerade die private methode __clone() gesehen in deinem quellcode. php.net sagt dass diese methode instanzen cloned jedoch verwenden die die dann in der eigentlichen methode das schlüsselwort clone dazu. hier ist der link http://de3.php.net/__clone

nun mein script funktioniert auch ohne clone. brauche ich es umbedingt??

EDIT2: achso

private __clone brauche ich damit von außen kein clone entsteht und private __construct damit von außen keine instanz angelegt werden soll. nun wird alle klar:D

Gebe ich dir recht, aber gibts dafür sinnvolle Alternativen? ;) Immerhin will man ja manche Dinge global haben (Logging, Datenbank, Einstellungen usw.). Singleton finde ich da am elegantesten, da man hier den Zugriff auf die Funktionalitäten und Daten komplett kapseln und absichern kann. 

Sicherlich.. kommt aber drauf an, wie dein gesamtes System aufgebaut ist. Eine Möglichkeit wäre das so genannte DI, und der simple Aufruf (in PHP) mittels $this->db oder $this->log. Selbstverständlich kann das ganze auch wieder eine abgeleitete Klasse sein, in welcher die Superklasse sich die Singletons über den Applikationscontroller/context/page/whatever holt. Oder via AOP (nicht PHP), wie gemacht für das Logging.

Will heißen: Möglichkeiten gibt es schon, aber in den meisten Fällen läuft es auf ein Singleton hinaus. Ich würde dennoch aus persönlichen Gründen das einmalige Setzen durch den verantwortlichen Controller/Context vorziehen.

Globale Variablen kann man ja überschreiben (ob absichtlich oder nicht, auf jeden Fall ist es ärgerlich sowas zu suchen... :))

Gut.. Klassennamen(!) kann man nicht überschreiben, wenn man den Scope berücksichtigt. Das wäre also kein Argument :)

oh man was wieder mal hier für ein disskussion startet:D ich freue mich schon richtig drauf mein gesamtes script zu veröffentlichen(nur hier intern denn die profis hier können eh bessere sachen auf die beine bringen) wenn die version 0.1 stable ist:D dann könnt ihr euch schön die zähne ausbeißen.und mich des besseren belehren(primärziel:D)

MFG

Ich hoffe du (BlackScorp) hast nichts dagegen, wenn ich eine weiterführende Frage stelle:

Wie würde man es "am Besten" lösen, wenn man mehrere Logger hat (und statt Singleton dem besseren Testen wegen auf DI setzt)?

Übergibt man statt einer Logger-Klasse dann mehrere (Liste) oder doch nur einen LoggerManager, der dann die Aufrufe der verschiedenen Logger steuert (mitm Observer-Pattern?). Ich denke letztere Variante ist flexibler, aber ich wollte einfach mal nachfragen...

LG

Original von altertoby

Ich hoffe du (BlackScorp) hast nichts dagegen, wenn ich eine weiterführende Frage stelle:

Wie würde man es "am Besten" lösen, wenn man mehrere Logger hat (und statt Singleton dem besseren Testen wegen auf DI setzt)?

Übergibt man statt einer Logger-Klasse dann mehrere (Liste) oder doch nur einen LoggerManager, der dann die Aufrufe der verschiedenen Logger steuert (mitm Observer-Pattern?). Ich denke letztere Variante ist flexibler, aber ich wollte einfach mal nachfragen...

LG

also willste sagen dass DI besser wäre anstatt Singleton? problem ist ich sehe zur zeit weder vorteile in singleton noch in DI noch sonstwo dazu fehlen mir zur zeit die nötigen kentnisse. das einzige was ichs ehen kann ist dass ich Singleton einfach umsetzen kann und dadurch auch noch ein "Schöneren" quellcode habe

MFG

Original von knalli

Sicherlich.. kommt aber drauf an, wie dein gesamtes System aufgebaut ist. Eine Möglichkeit wäre das so genannte DI, und der simple Aufruf (in PHP) mittels $this->db oder $this->log. Selbstverständlich kann das ganze auch wieder eine abgeleitete Klasse sein, in welcher die Superklasse sich die Singletons über den Applikationscontroller/context/page/whatever holt. Oder via AOP (nicht PHP), wie gemacht für das Logging.

DI hört sich für mich wie eine Fabrik an. Wenn man nur eine Datenbankverbindung braucht finde ich das etwas übertrieben, ansonsten hab ich bei mir eine Containerklasse die ein assoziatives Array von Datenbankverbindungen besitzt die ich mir per Name holen kann.

(Bzw. Generell hatte ich nicht die Datenbankklasse als Singleton gemacht, sondern noch ein Container aussenrum gepackt sodass die Datenbankklasse etwas Allgemeiner ist).

Will heißen: Möglichkeiten gibt es schon, aber in den meisten Fällen läuft es auf ein Singleton hinaus. Ich würde dennoch aus persönlichen Gründen das einmalige Setzen durch den verantwortlichen Controller/Context vorziehen.

Ja das ist ja kein Problem, man kann ja sowas wie eine "initInstance()" Methode machen die alle nötigen Parameter entgegennimmt und das Singleton Objekt instanziert.

Globale Variablen kann man ja überschreiben (ob absichtlich oder nicht, auf jeden Fall ist es ärgerlich sowas zu suchen... :))

Gut.. Klassennamen(!) kann man nicht überschreiben, wenn man den Scope berücksichtigt. Das wäre also kein Argument :)

Wieso kein Argument? Ich finde es einen großen Vorteil dass ich die Sicherheit habe dass nichts überschrieben werden kann. Bei globalen Variablen ist da immer ein Hintergedanke dabei, dass es eklig wird wenn man es aus versehen mal überschreibt, weswegen ich diese vermeide. :)

(Aus dem Grund vermeide ich auch sowas wie Zend_Registry, einfach ein globaler Container für Variablen. Das ist für mich nichts anderes als globale Variablen in OOP verpackt).

Original von BlackScorp

Original von altertoby

Ich hoffe du (BlackScorp) hast nichts dagegen, wenn ich eine weiterführende Frage stelle:

Wie würde man es "am Besten" lösen, wenn man mehrere Logger hat (und statt Singleton dem besseren Testen wegen auf DI setzt)?

Übergibt man statt einer Logger-Klasse dann mehrere (Liste) oder doch nur einen LoggerManager, der dann die Aufrufe der verschiedenen Logger steuert (mitm Observer-Pattern?). Ich denke letztere Variante ist flexibler, aber ich wollte einfach mal nachfragen...

LG

also willste sagen dass DI besser wäre anstatt Singleton? problem ist ich sehe zur zeit weder vorteile in singleton noch in DI noch sonstwo dazu fehlen mir zur zeit die nötigen kentnisse. das einzige was ichs ehen kann ist dass ich Singleton einfach umsetzen kann und dadurch auch noch ein "Schöneren" quellcode habe

MFG

Nein wollte ich nicht :)

Singleton hat den Zweck, dass du sicher gehst, dass nur eine Instanz deiner Klasse existiert. Das bietet sich an, wenn mehrere Instanzen deiner Klasse problematisch sind oder innhaltlich/vom Context her nicht möglich sein sollen. Z.b. du hast eine Klasse Finanzamt, da ist es logisch, dass es nur eins geben kann und mehrere zu Problemen führen kann (du reichst deine Steuererklärung ein und bekommst von dem anderen eine Mahnung, weil die Kommunikation zw. den Ämtern nicht stimmte).

DI erlaubt mehrere Instanzen einer Klasse, und ist ein Pattern um Abhängigkeiten in eine Klasse "einzuschleusen". Z.b. übergibst du deiner Produktionsklasse (für die Ressourcen-Produktion zuständig) eine Instanz deiner Logger-Klasse. Die speicherst du in der Prod.-Klasse als private Member ab, und jeden Logging-Fall reichst du an die Logger-Klasse weiter.

Vorteil ist, dass du die Produktionsklasse einfacher testen kannst (google: Stubs) und wenn du mehrere verschiedene Implementationen eines Logger hast (einen für die Consolen-Ausgabe während der Entwicklung, einer schickt dir eine Mail im produktiven Einsatz,...) kannst du einfach zw. diesen wählen, ohne die Produktions-Klasse zu ändern.

Um das mal korrekt abzustecken: DI sorgt für eine wesentliche geringe Kopplung (Abhängigkeiten) der verwendeten Komponenten. Im Beispiel "Geschäftsobjekt nutzt Datenbankobjekt" bedeutet dass, das die strenge Kopplung durch ein Singleton (hardcoded!) durch eine lose Kopplung ersetzt wird. Evtl. weiß die Geschäftsklasse tatsächlich nur ein Interface (ja, in PHP gibt es auch Interfaces). Das ist ein Vorteil zum Testen, aber auch für den universellen Einsatz.

Bezgl. mehrere Logger: In Java gibt es zwei große Logger (log4j sowie java.util's), die dies über eine Art LogManager/LogRegistry lösen. Ich vergleiche das gerne mit einer Art "multiplen Singletons", denn die Instanz wird für einen Schlüssel (String) angelegt und ist - wie ein Singleton - abrufbar. Ob man eine Loginstanz zusätzlich noch mit Logmodulen (Konsole, Datenbank, E-Mail, whatever) ausstattet, ist natürlich jedem selbst überlassen.

Es ist im Übrigen natürlich nicht ausgeschlossen, Singleton (DB) und DI gleichzeitig zu nutzen.. DI ist eine Frage der Kopplung und der Architektur, keine Frage der Datenbank.

Original von knalli

Um das mal korrekt abzustecken: DI sorgt für eine wesentliche geringe Kopplung (Abhängigkeiten) der verwendeten Komponenten. Im Beispiel "Geschäftsobjekt nutzt Datenbankobjekt" bedeutet dass, das die strenge Kopplung durch ein Singleton (hardcoded!) durch eine lose Kopplung ersetzt wird. Evtl. weiß die Geschäftsklasse tatsächlich nur ein Interface (ja, in PHP gibt es auch Interfaces). Das ist ein Vorteil zum Testen, aber auch für den universellen Einsatz.

Meine Datenbankklassen implementieren Interfaces, also wäre das Geschäftsobjekt nur vom Interface abhängig. Bzw. wenn man ein ORM nutzt wäre es nur von der Datenklasse abhängig. Im Falle vom DI sind dann alle vom DI abhängig. Also tauscht man eine Kopplung durch eine Andere aus, oder übersehe ich hier etwas?

Erstens: DI ist ein Muster, kein Objekt oder Interface. Wie ein Singleton, eine Fabrik oder DAO.

Zweitens: Wie erhält dein Geschäftsobjekt denn das konkrete Datenbankobjekt? Das ist der (und zwar der einzige) Punkt, an dem DI ansetzt.

Ich denke knalli meint, dass du mit DI die Kopplung nur beim erzeugen kennen musst. Die Klasse, die per DI die Kopplung übergeben bekommt ist danach "lose", denn sie greift ja auf was übergebenes, unbekanntes zu. Wenn du in der Klasse statt per DI das Singleton immer direkt ansprichst, hast du stärkere Kopplung.

Insgesamt verstehe ich aber nicht ganz warum DI <-> Singleton gestellt wird. Um das Singleton kommt man irgendwo nicht sinnvoll drumrum (egal ob es jetzt ein Manager ist). Und DI für das Singleton oder init... etc halte ich für Schwachsinn. Nutzt man ein Singleton braucht dieses besonders bei DB auch nur eine Konfiguration. Möchte man andere Testdaten nutzen, macht man eben 2 Konstruktoren (weiß grad nicht wie gut das bei PHP ging, aber allgemein bei OOP ja ganz normal - also ein Standardkonstruktor ohne Argumente und einen mit der Datenbankverbindung).

Erst wenn man mehrere Datenbankverbindungen haben möchte braucht man DI schon beim erzeugen der Datenbankverbindung. (Logisch, imho ist DI aber auch kein Entwurfsmuster wie bei Wikipedia gesagt; der Artikel von Fowler ist nicht sehr interessant imho, da übergabe von Abhängigkeiten über den Konstruktor durchaus normal ist *g*). Dennoch braucht man dann einen DatenbankManager, der die verschiedenen Datenbankverbindungen zur verfügung stellt (wenn man nicht jedes mal parametrisiert das Singleton erzeugen will).

Hier gibt es übrigens eine Blog-Reihe über DI (engl.).

edited - entfernt ;) 

eben 2 Konstruktoren (weiß grad nicht wie gut das bei PHP ging, aber allgemein bei OOP ja ganz normal - also ein Standardkonstruktor ohne Argumente und einen mit der Datenbankverbindung).

Und das ist ein weiteres NoGo in Datenbankklassen, die immer gemacht werden: Man packt die Konfiguration in den Programmcode. Sprich: Immer einen Konstruktor mit den Daten (wie auch immer, und wenn es der Dateiname einer XML-Konfiguration ist) nutzen. Das sind weniger Kopplungen, die einen eines Tages Arbeit sparen wird.

Insgesamt verstehe ich aber nicht ganz warum DI <-> Singleton gestellt wird. Um das Singleton kommt man irgendwo nicht sinnvoll drumrum (egal ob es jetzt ein Manager ist). Und DI für das Singleton oder init... etc halte ich für Schwachsinn. Nutzt man ein Singleton braucht dieses besonders bei DB auch nur eine Konfiguration. Möchte man andere Testdaten nutzen, macht man 

Singletons werden aus zwei Gründen gemacht -- und bitte nicht falsch verstehen, ich nutze die auch: Globale Erreichbarkeit und explizite Einzigartigkeit. Beides kann mit DI gelöst werden, aber beides kann auch mit beiden Methoden erreicht werden.

Beispiel: Wenn das Geschäftsobjekt einen Setter wie setDatabase(Database $databaseObj) besitzt, dann muss der Context/Controller (also die Komponente, die das Geschäftsobjekt im gesamten Framework initialisiert und ausführt) nur jene Methode setzen. Damit ist a) die Datenbank im Objekt verfügbar (Erreichbarkeit) und b) die Einzigartigkeit gegeben. Natürlich gibt es den Schwachpunkt, dass es 2 Contexts/Controllers gleichzeitig geben könnte. Dann aber hat man einen schweren Designfehler.. :)

Der Punkt ist: Das Geschäftsobjekt hat absolut keinen Peil, wie eine Datenbankklasse heißt oder welcher DB-Manager das wissen könnte.. es ist absolut irrelevant. 

Aber wie ich bereits oben sagte, das ganze kriegt man auch mit vererbten Objektattributen hin. Ist keine DI, sieht aber im Ergebnis und der Verwendung ähnlich aus.

*ok mal ne andere Frage in den raum werfen* was ist ein pattern und wozu dient es? also laut wiki ist es ein entwurfsmuster aber irgendwie kann ich mir das noch nicht so vorstellen. könnte jemand mir anhand eines kleinen beispiels erklären? denn ich habe ziemlich oft hier im forum das stichwort gehört

MFG

Ein Designpattern bzw. Entwurfsmuster ist eine für gut befundene wiederverwendbare Programmierlösung für ein häufig wiederkehrendes Problem.  Sozusagen eine Standardlösung für ein Programmierproblem.  Kennen alle Mitglieder des Teams die verwendeten patterns, so folgt der Theorie zusätzlich noch, dass der geschriebene Code viel schneller von allen Teammitgliedern verstanden werden kann.

Original von Sarge

Ein Designpattern bzw. Entwurfsmuster ist eine für gut befundene wiederverwendbare Programmierlösung für ein häufig wiederkehrendes Problem.  Sozusagen eine Standardlösung für ein Programmierproblem.  Kennen alle Mitglieder des Teams die verwendeten patterns, so folgt der Theorie zusätzlich noch, dass der geschriebene Code viel schneller von allen Teammitgliedern verstanden werden kann.

ahh das ist verständlich danke für die info

@knalli
An eine XML als Konfiguration hatte ich durchaus gedacht, aber auch im Code. Aber ja, es ist leichter wartbar wenn man immer den Aufruf macht und dann braucht man genaugenommen kein Singleton mehr (weil man ja eh per DI stets die Konfiguration übergibt).

Und wenn ich dein Beispiel richtig verstehe: Du erzeugst einmal die Datenbankklasse (Konfiguration per DI) und gibst sie an das Geschäftsobjekt. Alle anderen Klassen beziehen über das Geschäftsobjekt dann die DB-Klasse (vermutlich statischer getter)?

Oder meinst du, dass jeder Klasse, die die DB braucht dieser per DI übergeben werden soll? Verringert natürlich die Scope drastisch (ist dann ja nurnoch lokal), aber stelle ich mir recht unübersichtlich vor die stetig weiterzureichen.

Und allgemein, falls man immer eine neue DB-Klasse erstellt => das geht doch enorm an die Laufzeitkosten oder sehe ich das falsch? Dachte immer das DB-Singleton hat einen großteil des Sinnes auch darin, nur eine Verbindung aufzubauen und darüber alle Queries zu schicken, bis die Logik fertig ist.

(Danke auf jeden Fall fürs zurechtweisen, man lernt doch gern stets was dazu. :))

An eine XML als Konfiguration hatte ich durchaus gedacht, aber auch im Code. Aber ja, es ist leichter wartbar wenn man immer den Aufruf macht und dann braucht man genaugenommen kein Singleton mehr (weil man ja eh per DI stets die Konfiguration übergibt).

Man kann natürlich auch mittels DI die Konfiguration einladen, das ist richtig. Das ist dann aber eine Ebene "höher" angesiedelt.

Und wenn ich dein Beispiel richtig verstehe: Du erzeugst einmal die Datenbankklasse (Konfiguration per DI)

Bitte nichts durcheinander würfeln.. DI ist das "inverse Holen" der Objekte, sprich als "geben". Mehr ist da nicht, auch keine Objektkonstruktionen. Aber ja, einmal erstellen.

und gibst sie an das Geschäftsobjekt. Alle anderen Klassen beziehen über das Geschäftsobjekt dann die DB-Klasse (vermutlich statischer getter)?

In PHP: public void setDatabase() und zusätzlich der entsprechende Getter: public Database getDatabase(). Wahlweise kann der Getter natürlich auch private/protected sein. Genauso kann man natürlich auch mit einer normalen Generalisierung/Vererbung arbeiten (Problem: Nur ein Superklasse möglich). Und natürlich kann man auch statt einem Getter direkt auf $this->databaseObj arbeiten.

Oder meinst du, dass jeder Klasse, die die DB braucht dieser per DI übergeben werden soll? Verringert natürlich die Scope drastisch (ist dann ja nurnoch lokal), aber stelle ich mir recht unübersichtlich vor die stetig weiterzureichen.

Die Frage ist ja: Wer braucht bei dir denn alles Datenbankzugriff? Woher kommen diese Klassen und wer erstellt und führt sie aus? Die Objekte müssen für die Anwendung von DI natürlich über einen gemeinsamen Context geladen worden, sonst führt es doch zu Abhängigkeiten, das wäre ja absurd.

Und allgemein, falls man immer eine neue DB-Klasse erstellt => das geht doch enorm an die Laufzeitkosten oder sehe ich das falsch? Dachte immer das DB-Singleton hat einen großteil des Sinnes auch darin, nur eine Verbindung aufzubauen und darüber alle Queries zu schicken, bis die Logik fertig ist.

Es wird ja weiterhin nur ein Objekt erstellt; bei Datenbankklassen geht es zwar auch um Laufzeit, es geht aber auch um das Problem multipler Verbindungen, welche unschöne Nebeneffekte haben. Ich empfehle das studieren der entsprechenden Wikipediaseiten für einen Ersteindruck. Muster im Allgemeinen sollten jedem Programmierer nicht nur bekannt sondern auch geläufig sein; DI ist dabei aber sicher ein Kandidat, der speziell und nicht als erstes Muster geeignet ist :)

Na mit Entwurfsmustern komme ich imho ganz gut klar. :) Sorry für die Unklarheit: Wenn ich von Dependency Injection rede, meine ich idR Constructor Injection (und dann hat es ja zwingend was mit Instanzbildung zu tun). Mag ich einfach lieber als Setter oder Service Locator.

Hmja, dürfte so sein, dass nur wenige Klassen die DB brauchen und dann ist DI natürlich sehr schick um das wartbar und mit lokalem Scope zu belassen. Musste mir noch nicht so viele Gedanken drüber machen, weil einem die Frameworks heutzutage ja eigentlich komplett abnehmen. ^^ Aber danke für die Klarstellungen, hab soweit keine Einwände / Fragen mehr.

Edit: Nochmal eine berichtigung zu den Entwurfsmustern: Ich weiß ziemlich gut wie man sie anwendet, aber wann genau & welche Nachteile das mit sich bringt ist ja meist weniger gut hervorgehoben. Dahingehend hab ich durchaus nachholbedarf. *g*

Sogesehen könnte man das natürlich vergleichen, der Unterschied zwischen Setter und Constructor (unabhängig von DI) ist: Constructorparameter sind absolut zwingend notwendig, Setter sind optional. Man sollte von dem Objekt also erwarten, dass ein nicht gesetzter Setter keine Abstürze o.ä. produziert, gleichermaßen aber ein null-Argument im Constructor zu Problemen führen kann (sofern nicht explizit angegeben, vgl. Java-Swing).