Flor1an

Naja es läuft so das ich eben in meiner header.php die Klasse initialisiere und dann kann ich im Skript einfach mit $db->query(...); etwas aufrufen und in der footer.php steht dann nochmal $db->close(); und die Klasse selber macht das mit dem Connect zur DB.

Also die Klasse macht solange nichts bis das erstemal query() aufgerufen wird. Dadurch verbindet sie sich zur Datenbank und sendet den Query. Und wenn close() aufgerufen wird schaut die Klasse ob überhaupt eine Verbindung erstellt wurde, wenn ja dann schließt sie die Verbindung ansonsten tut close() nichts.

Ich hab z.B. in meiner Klasse nen paar Sachen anders gemacht als sie die mysql Funktionen machen würden. Z.B. kann ich $db->fetch_array("SELECT * FROM table"); aufrufen. Die Funktion fetch_array() schaut dann ob der übergebene Parameter nen String ist .. dann wird erst noch query() aufgerufen wenn nicht dann wird gleich mysql_fetch_array aufgerufen. So spar ich mir halt bissi arbeit ... muss halt netmehr $db->fetch_array($db->query("...")); schreiben und so Kleinigkeit was aber des arbeiten schon etwas erleichtert und übersichtlicher macht.

Mister Ad

Promaetheus

hm.... klingt super... aber kompliziert für mich als klassenneuling.

__________________
mfg Alexander Haim

nikosch

wie gesagt kannst du verschiedene datenbanken oder aber auch verschiedene authentifizierungsparameter verwenden (und so z.b. nur lesen connections oder dergl. herstellen, eben was datenbank user-management so hgergibt). das ganze kannst du dann noch auf einen parameter herunterbrechen, so verbindet ::connect ('INTERN') dann halt mit allen rechten, ::connect ('BASIC') nur zugriff auf eine bestimmte tabelle oder so.
benutzt du ein zentral verwaltetes singleton objekt kannst du aus unabhängigen modulen ohne übergabe des handlers auf das DB objekt zugreifen usw. usf.

nicht zu vernachlässigen ein eigens fehlermanagement, was es dann auch ermöglicht, bestimmte funktionen in einer methode zu vereinigen.
du kannst query results im cache zusammen mit der anfrage ablegen, ... es gibt schon einige sinnvolle gründe für eine klasse.

Promaetheus

ok. SOWEIT bin ich nochlange nicht. also denke ich dass für mich die funktionen oder eine einfache db-verbindungsklasse reichen. bin ja noch nicht auf so hohem level und tu mich mit der oop sehr schwer.

__________________
mfg Alexander Haim

dr.e.

Hallo Promaetheus,

Klein anfangen ist gut, denn so lernt man seine Komponenten verstehen. Nach und nach wirst du dann sehen, wo die Probleme sind, wirst selbst anfangen weiterzuentwickeln und dann sehen, dass es einige Dinge gibt, die du genauso machen würdest.


OOP ist erst mal garnicht das Thema, viel mehr Wert sollte auf OOD (=Objektorientiertes Design) gelegt werden. Für dich reicht aber auch erst mal ein modulares Design. Wenn man sich vorher Gedanken macht, wie das auszusehen hat ist es hinterher garnicht so schwer in PHP-Code zu fassen.

Zum Design:
Hier finde ich den Ansatz von nikosch77 interessant, eine Abstraktions-Schicht einzuziehen, die nochmal entscheidet, was die darüber liegende Schicht darf uns was nicht. Ebenso kann es Sinn machen eine weitere abstrakte Treiberschicht einzuziehen, damit man mit unterschiedlichen Datenbanken arbeiten kann. Treibt man das auf die Spitze, so setzt man das Domain-Object-Pattern ein. Hierbei wird das Datenmodell der Datenbank völlig vom Datenmodell der Anwendung getrennt. Es findet immer dann Einsatz, wenn mehrere Projekte auf eine und derselben Datenbank und oft auf die gleichen Tabellen zugreifen. Ich habe sowas in meiner Diplomarbeit gemacht. Dort habe ich 1-n Projekte auf den selben Tabellen gehostet. Die Daten-Schicht bestand aus 2 Unterschichte:

- MySQLHandler
- DataMapper

Der MySQLHandler implementiert die MySQL-Spezifika und stellt abstrakte Methoden wie executeStatement() oder getLastID() zur Verfügung. Der Mapper generiert nun mit Hilfe von SQL99-kompatiblen Statements (könnten auch gegen eine Postgre-SQL gehen) Objekte, bzw. Objektbäume, die die Anwendung verstehen kann. Beispiel wäre eine "Veranstaltung", an deren Attribut "Dozenten" weitere Objekte vom Typ "Dozent" hängen. Somit kann es der Anwendung egal sein, welche Datenbank darunter für die Speicherung der Daten sorg, solange die Anwendung die für sie verständlichen Daten bekommt. Ob nun eine MySQL schneller oder langsamer als eine Prostgre-SQL ist kann man sich streiten, denn um Performance geht es bei solchen Konzepten (erst mal) nicht.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~