Ein Shop braucht natürlich Zugriff auf eine Datenbank. Also fing ich mit einer Klasse "DB" an, welche die Verbindungsdaten zur Datenbank erhält und sämtliche Zugriffe auf die Datenbank kapselt. Nirgendwo außerhalb der DB-Klasse sollte auch nur das kleinste Fitzelchen SQL stehen.
Nun ist so ein Entwurf gut? Außer bei sehr kleinen Dingen würde ich sagen, nein.
Aus den Daten in der Datenbank wird man ja tpyischerweise ein Datenmodell aus Objekten aufbauen. Je komplexer die Anwendung wird, desto mehr Komponenten wird es geben, die irgendwie ein Datenmodell aus Daten in der Datenbank aufbauen.
Die gesammte Information, wie diese Modelle aufgebaut werden, wird in der Datenbank-Klasse stecken. Jede Änderung an einem Datenmodell wird eine Änderung an dieser Klasse bedeuten d.h. diese Anwendung vereint Logik von Komponenten, die ansonsten pratkisch nicht gekoppelt sind.
Ich habe bei solchen Anwendungen typischerweise eine Klasse, die die Verbindung zur Datenbank herstellt, und sehr viele Klassen, die diese benutzen und auf die Datenbank zugreifen.
Das wirft natürlich das Problem auf, dass die Datenbankzugriffe irgendwie abgestimmt sein müssen.
Das kann man entweder lösen, indem man jeder Klasse ihre eigenen Tabellen zuordnet und die Komponenten sind dann nur auf Anwendungsebene verknüpft. Die andere Möglichkeit ist, dass man einen Großteil diese "Modellerzeugungsschicht" direkt in der Datenbank implementiert.
Wenn man mit MySQL (speziell mit älteren Versionen) auskommen muss, kann man Letzteres nicht umsetzen, auch wenn es die bessere Lösung ist.
Grüße
Daniel