Philipp Hasenfratz: Lohnt sich hier ein Objekt-orientierter Ansatz?

Beitrag lesen

Halihallo

du bastelst dir eine eigene Klasse als Datenbank-Interface mit obengenannten Methoden. Jedesmal, wenn du eine DB-Connection brauchst, erstellst du eine neue Instanz der Klasse und kannst diese verwenden.

Ja, sowas wie Andrés Vorschlag, oder?

Ja, sogar genau das, nur hatte ich andere Methodennamen.

Ich muß mal gucken was mir mehr liegt, das mit den Funktionen sieht wie ich finde auf den ersten Blick etwas leichter und weniger zu schreiben aus.

Das stimmt, nur kannst du dann nur eine Instanz der Connection offen haben (oder nur mit ziemlichem Aufwand das Multiconnection-fähig machen). Wenn du verschachtelt SQL-queries schicken willst, geht das nicht mehr. Einfaches Beispiel:

<pseudocode>
SQL: SELECT * FROM Kunden
foreach (Kunde) {
   SQL: SELECT * FROM Articles
}
</pseudocode>

Ich weiß auch nicht, ob OOP für sowas so optimal ist, wenn ich nicht irre ist das auf alle Fälle langsamer und außerdem weiß ich nicht, was man von den ganzen Klasen.. usw. hat, wenn man eh immer nur ein Script hat, welches von vorne bis hinten für sich als eigenes Programm ausgeführt ausgeführt wird, das ist nunmal ein Job für eine Scriptsprache, wie der Name schon sagt, ich weiß nicht ob OOP das an so einer Stelle nur verkomplizieren.

Auf jeden Fall langsamer? - OK, 1 Milisekunde, aber höchstens. Langsam wird's erst, wenn man's nicht richtig programmiert ;)
Gut, ich weiss nicht, wie OOP in php implementiert ist und wie performant das gelöst ist, aber viel Prozessorzeit wird damit wohl nicht verbraten (gegenüber einer prozeduralen Lösung).

Genau wie z.B. eine Warenkorb Klasse, das ist ja in der Theorie wirklich ganz nett, aber in der Praxis? Ich gebe was in den Warenkorb... und dann? Wenn ich ein weiteres Produkt suche muß ich auf eine andere Datei wechseln, die Datei mit der Warenkorb-Klasse wird beendet, die Daten sind weg - wozu soll das dann gut sein?

Im Hauptprogramm musst du dich nicht mehr um SQL-queries kümmern, sondern kannst dich voll und ganz auf das Interface der Klasse beschränken. Falls dann künftig Änderungen am Datenbankschema kommen, musst du nur noch die Klasse ändern, alle GUI-Programme bleiben dieselben. D. h. Du trennst Output von der Funktionalität. Zudem kannst du eventuell eine ganze Klasse (was bei einer DB-Klasse sicher der Fall ist) in einem anderen Programm wiederverwerten => Wiederverwertbarkeit von Code und musst nicht alles kopieren.

Mir ist bis jetzt noch kein Einsatzzweck bei einem Webobjekt wie einen DB-gestützen Online-Shop untergekommen, wo ich Klassen auch nur irgendwie für besonders nützlich oder vereinfachend empfunden habe.
Aber vielleicht habe ich ja noch ein allgemeinerers Verständnis-Problem mit OOP ;-)

Hm. Vielleicht können wir das ja beheben; ich liebe (und das musste ich auch zuerst lernen) nämlich OOP ;)

Zu den Fehlermeldungen: Wenn ein Fehler auftaucht, sollte das Programm gleich abgebrochen werden.
Das mach ich ja durch die();

Upsa, das hab ich übersehen, 'tschuldige

Viele Grüsse

Philipp