nicht angemeldet
echo $begrüßung;
Urpsprünglich wollte ich zum Beispiel eine Datenbankklasse haben die sämtliche Datenbank-Methoden enthalten sollte erstellen.
Das und auch der nachfolgende Text liest sich so, als ob du die eierlegende Wollmichsau programmieren willst. Doch mit all den Funktionen steigt auch die Komplexität des Systems und damit der Wartungsaufwand.
Hast du dir zunächst erst einmal Gedanken darüber gemacht, welche(s) konkrete(n) Problem(e) du damit zu lösen versuchst?
Unter Verwendung von MySQLi, sollen auch prepared Statements dynamisch erstellt werden können.
Wenn du sowieso das Statement dynamisch und noch dazu bei jedem Scriptaufruf erneut zusammenbaust ist als Vorteil von Prepared Statements nur noch das Nichtbehandelnmüssen der Werte übrig geblieben. Das erkaufst du dir auch noch durch recht umständliches Handling der Parameter- und Result-Bindung. Es ist dann möglicherweise sogar weniger aufwendig und performanter, das Statement auf herkömmliche Weise zusammenzubauen, inklusive händischer Maskierung und Quotierung. Hinzu kommt noch, dass du das Ergebnis-an-Variable-Binden gar nicht gescheit nutzen kannst, wenn du das Resultset als Ganzes den Abnehmern zur Verfügung stellen willst.
Nun. prepare() braucht aber zum Beispiel das erstellte Datenbankobjekt.
Das kannst du dir ja mit Hilfe des Singleton-Pattern besorgen.
Also war mir schonmal klar, die erweiterten DB-Funktionen und die Haupt-DB-Funktionen(connect, close z.B.) können nicht in einer Klasse stehen.
Connect und Close muss die Hauptklasse von selbst machen. Dies sollte man nicht den Anwendern (sprich: anderen Programmteilen) überlassen, denn die wissen ja gar nicht, wann der beste Zeitpunkt zum Öffnen und Schließen ist. Es ist ja nicht sinnvoll, dass das mehrfach im Script passiert. - Und damit hast du gleich noch die nächste Frage: Wann ist der beste Zeitpunkt für ein Close? Im Grunde genommen kannst du nur darauf verzichten. Die DB-Klasse weiß nicht ob noch weitere Anforderungen kommen und die Anforderer wissen auch nicht, was nach ihnen noch passieren wird. Die DB-Klasse weiß lediglich welches die erste Anforderung ist und kann dafür die Verbindung eröffnen. Weitere Anforderer bekommen dann diese offene Verbindung.
Wobei man das ganze System am besten als Lazy Connect aufbaut. Ein Bedarfsträger kann zwar die DB-Klassen-Instanz anfordern, muss aber nicht zwangsläufig Funktionen verwenden, die eine DB-Verbindung brauchen. Deswegen muss nur jede Funktion, die eine Verbindung braucht, prüfen, ob diese schon offen ist, ansonsten sie eröffnen. Schau dir mal an, wie das im Zend Framwork gelöst ist.
Da aber alle Klassen die DB-Methoden haben müssen, sprich erben werden und PHP nur eine einzige Vererbung pro Klasse _direkt_ zulässt, habe ich mich dazu entschlossen eine "Main_Class" zu erstellen die in jede Klasse eingebunden wird.
Zur Not gäbe es immer noch das Decorator-Pattern. Aber das würde ich jetzt nicht als Lösung deines Problems ansehen sondern eher eine bessere Strukturierung und Arbeitsteilung.
Vor allem weiß ich garnicht mehr wo das DB-Objekt erstellt werden soll.
Die Geschäftslogik muss eigentlich gar nicht wissen, dass es da eine DB-Klasse gibt. Sie sollte nur wissen, wie sie an bestimmte Daten kommt. Sie sollte sich idealerweise auch gar nicht um das Zusammenbauen der SQL-Statements und dem Hantieren mit der Datenbank befassen müssen. Ein Funktionsaufruf, der ein Ergebnis liefert - fertig. Der Rest ist Blackbox.
Klappt man den Deckel der Blackbox auf, sieht man zunächst konkrete Datenlieferanten, die aus den Eingabeparametern die Anfrage zurechtbauen und ein Ergebnis zurückliefern. Schaut man tiefer, sieht man, dass die sich bei grundlegender benötigter Funktionalität bei einer gemeinsamen Basisklasse bedienen oder andere Klassen damit beauftragen (auch die DB-Hauptklasse).
Desweiteren müssen alle "Standard-Funktionen", sprich Funktionen die ich mir erstellen werde die man öfters mal braucht wie z.B. "requests2array", "timestamp2date" - die Namen sind wohl selbsterklärend, in der Main_Class stehen.
Wo auch immer sie am besten aufgehoben sind. Vielleicht ist es sinnvoll, eine Helper-Klasse zu erstellen, die eine Reihe von statischen Funktionen bereithält, die einfach so aufgerufen werden können, sprich: keine DB-Funktionalität benötigen.
Übersichtlich und dennoch möglichst performant.
Je weniger Code verwendet wird, desto näher kommt man im Allgemeinen an beide Ziele.
echo "$verabschiedung $name";