Sql query auslagern?

[lalaland]

Hi,
ich schreibe grade eine DbManager class in dieser werden die Datenbankabfragen getätigt. Meine Frage ist würdet ihr die query´s in eine extra class auslagern? Zum Beispiel class Sqlquerys und diese dann einfache per get Funktion in die Managerclass holen. Oder sind die dort aufgehoben? Die frage kam auf Grund der Übersichtlichkeit auf. Der zweite Punkt wäre bremst das Auslagern die Abfragen extrem aus oder ist es zu vernachlässigen?
Mfg Lalaland

[h3ll]

Warum tätigt die DbManager Klasse irgendwelche Datenbankabfragen?

[AmicaNoctis]

Hallo,

den Namen nach tendierst du zu einer oft beobachteten Arbeitsweise, bei der Klassen nach deren Aufgabe eingeteilt werden. Das führt praktisch dazu, dass du im Grunde prozedural arbeitest und die Klasse nur noch einen Namespace für die Funktionen darstellt. Solche Dinge wie ...Manager sind meistens schon ein Hinweis darauf, dass der Entwurf nicht stimmt.

Besser: Klassen nach dem einteilen was sie sind und repräsentieren. Z. B. Database, Table, Row, ResultSet, ClientModel, Client u. s. w.

Gruß,

Amica

[lalaland]

Na ja evlt ist meine Klassenbeschreibung auch falsch. Ich will einfach eine Klasseerstellen in der alle Einträge in die Datenbank gemacht und alle ausgaben abgefragt werden können. Evtl kann man das ja noch mal in eine SetDB und eine GetDb Klasse oder so unterteilen. Über diese Klasse(n) sollen die Daten dann an das Ausgebe Template weiter gegeben werden.
Mfg Lalaland

[h3ll]

Und warum ist das _eine_ Klasse? Hast du nur eine Tabelle in der Datenbank? Pro Tabelle sollte zumindest eine Klasse existieren. Sinnvollerweise sind es mindestens zwei (eine Klasse, die für die Datenbankabfragen zuständig ist und eine Klasse, die die Daten enthält). Und anhand der Klassennamen sollte auch erkennbar sein, um was es sich eigentlich handelt.

[lalaland]

Hm.. ich dachte das ich pro Tabelle eine Funktion mache.

[h3ll]

Das hat dann aber nichts mehr mit OOP zu tun. Da kannst du gleich prozedural programmieren.

[AmicaNoctis]

Das klingt nicht sinnvoll. Am besten du erstellst erst einmal eine Klasse für jede Art von Ding in deiner Datenbank, z. B. Address, User, Product, Order, ... und baust die zugehörigen Getter und Setter ein, z. B. Address->getStreet/setStreet(), User->getAddress().

Dann baust du Model-Klassen für logisch zusammengehörige Bereiche, z. B. UserModel mit Methoden wie getUsersByLastName(), getUsersByCity(), createUser(), insertUser(), updateUser(), ... und OrderModel mit getProductGroup(), getProductByEAN(), getOrdersByUsername(), getUnshippedOrders().

[h3ll]

Dann baust du Model-Klassen für logisch zusammengehörige Bereiche, z. B. UserModel mit Methoden wie getUsersByLastName(), getUsersByCity(), createUser(), insertUser(), updateUser(), ... und OrderModel mit getProductGroup(), getProductByEAN(), getOrdersByUsername(), getUnshippedOrders().

Das hat aber nichts im Model verloren, das gehört ins Repository. Im Model werden nur die Daten und die Relationen abgebildet.

[lalaland]

Hm... Das werde dann aber viele Klassen oO. Na ja aber stimmt schon dann lassen sich die Abfragen für die einzelnen Tabellen leichter erweitern, wenn noch abfragen dazu kommen.

[h3ll]

Hm... Das werde dann aber viele Klassen oO. Na ja aber stimmt schon dann lassen sich die Abfragen für die einzelnen Tabellen leichter erweitern, wenn noch abfragen dazu kommen.

Es war auch nie das Ziel möglichst viel Code in möglichst wenig Klassen zu stopfen.

[AmicaNoctis]

Hm, da PHP-Anwendungen meist sehr kurzlebig sind, habe ich bisher keinen Nutzen darin gesehen, das Repository Pattern zu benutzen, aber danke für den Denkanstoß.

[lalaland]

Das klingt nicht sinnvoll. Am besten du erstellst erst einmal eine Klasse für jede Art von Ding in deiner Datenbank, z. B. Address, User, Product, Order, ... und baust die zugehörigen Getter und Setter ein, z. B. Address->getStreet/setStreet(), User->getAddress()

Also erst mal Kontainerkassen erstellen sehe ich das richtig. In diese werden die Daten eingespeißt und diese geben sie auch wieder zurück. Alles klar.

[h3ll]

Hm, da PHP-Anwendungen meist sehr kurzlebig sind, habe ich bisher keinen Nutzen darin gesehen, das Repository Pattern zu benutzen, aber danke für den Denkanstoß.

Wenn du es so siehst, kann ja gleich auf jeden sauberen Ansatz verzichten, weil es eh nur kurzlebig ist

Ich arbeite an Anwendungen mit einer Entwicklungszeit von mindestens einem Jahr. Wäre ziemlich schade, wenn man diese Arbeit nach 2, 3 Jahren wieder wegwirft und von vorne beginnt.

Mal davon abgesehen ist ja der große Vorteil von OOP die Wiederverwendbarkeit. Wenn du damit nur kurzlebige Anwendungen programmierst und danach alles wegwirfst, verzichtest du auf diesen Vorteil.

[AmicaNoctis]

Genau, worauf du dabei aber unbedingt verzichten solltest, ist jegliche Anbindung dieser Klassen an die Datenbank. Diese Klassen sollten relativ dumm sein und nichts anderes können, als die Daten, die ihnen eingehämmert wurden, wiederzugeben. Auf keinen Fall dürfen Sie sich diese Daten selbst besorgen oder Änderungen in die Datenbank zurückschreiben können.