nicht angemeldet
Moin!
Hallo,
danke erstmal dafür das du dir die Zeit genommen hast, mir eine so auführliche Antwort zu schreiben.
Ich empfehle dir wirklich sehr, dass du dir mal die verlinkte Seite durchliest und dir das Framework herunterlädst.
Danke für den Tip. Ich werde mir das auf jedenfall genauer anschauen.
Wenn du Datenbankzugriff hast, dann bedeutet das automatisch, dass du eine Datenbankzugriffsklasse hast
Nein bis jetzt habe ich noch keine Klasse die alle Datenbankzugriffe regelt. Ist aber schon auf meiner ToDo Liste.
Nirgendwo sonst, außer in der DB-Klasse, tauchen irgendwelche mysql-Befehle auf.
Die mysql-Befehle werd ich aus meinen Klassen entfernen. Das wird dann gleich in einem rutsch mit der Datenbankzugriff-Klasse gemacht.
Die erste spannende Design-Entscheidung beim Programmieren: Wo stehen die SQL-Querys, die die DB-Klasse letztendlich ausführen soll.
Wenn das Datenmodell klein, überschaubar und garantiert nicht erweiterbar ist, könnte man die Querys auch noch mit in die DB-Klasse packen. Das ist aber keine gute Idee. Erstens bläht sich die Klasse dann mit Methoden auf, die im Zweifel doch immer mehr werden. Zweitens lassen sich, wie erwähnt, "Border-Klassen" nur schlecht testen, man muß die DB real laufen haben, und echte Querys kosten Zeit.
Deshalb ist es schlauer, davor eine Art Layer zu packen, der in der Realität die DB-Klasse verwendet ... Da es vermutlich höchst unterschiedliche Abfragen aus der Datenbank zu unterschiedlichen Themengebieten gibt, wird es mit Sicherheit auch mehr als eine solche Layerklasse geben.
Also ein Klasse die für eine andere Klasse per Anfrage entsprechende Daten aus der DB zieht und diese dann zurück gibt?
Klasse User will DB Daten -> Anfrage an Klasse Layer_User -> DB Abfrage -> DB Daten als Objekt an User zurückgeben
Hab ich das richtig verstanden?
Was noch typische Dinge sind, die sich für eine Klasse eignen:
- Sessiondatenzugriff.
- Zugriff auf Browserdaten ($_GET, $_POST)
Das steht ebenfalls schon auf meiner ToDo-Liste
$erg = mysql_query(
"SELECT suchname_id " .
"FROM prod_such_zuo " .
"WHERE produkt_id='$produkt_id'"
);
Es ist schlecht, den DB-Query direkt in der Klasse zu haben.
Da wären wir doch wieder bei der Layer Lösung, oder?
Zweitens würfelst du PHP4- und PHP5-Objektorientiertheit durcheinander. In PHP 4 mußte der Konstruktor als Funktion den Namen der Klasse tragen, und es gab keinen Destruktor. In PHP 5 heißt der Konstruktor als Funktion immer "__construct", und der Destruktor "__destruct"
Danke, dass hab ich nicht gewusst. Habe das bisher immer so gemacht und seid ich eclipse nutze wird das schon automatisch so eingefügt.
Werd ich ändern, vor allem gefällt mir die __construct Variante eh besser.
Üblicher erscheint mir stattdessen, dass ein "Hauptobjekt" aus der Tabelle n ausgelesen wird, und alle damit tatsächlich (über die n:m-Hilfstabelle) verknüpften Einträge aus m werden in dieses Objekt ebenfalls hineingetan, z.B. als Array.
Also ein zweidimensionales Array das als Objekt zurückgegeben wird und alle Beziehungen zwischen m und n enthält?
Das Hauptobjekt müsste mir ja genau das zurückgeben was ich in dem Moment suche. z.b. wenn ich n angebe will ich alle m die zu n gehören. Genauso andersrum.
Soll ich da zwei seperate Klassen erstellen oder eine flexible?
- Sven Rautenberg
Vielen Dank nochmal für deine Mühe.
Gruß
Andre