Tach!

die ORMs die ich kenne machen das alle so dass sie die grundlegenden CRUD-Operationen (create, read, update, destroy) direkt am Objekt machen, so weit ich mich erinnere nennt man das Active record pattern und ich finde ihn leicht verständlich und leicht implementierbar, dafür aber nicht so mächtig wie das was du beschreibst.

Naja, leicht verständlich ist das mit dem Datenkontext auch, zumindest mit dem Entity Framework unter .NET. Schau mal auf [http://www.asp.net/mvc/tutorials/mvc-music-store/mvc-music-store-part-5]. Leider hat die Seite keine Anker zum Direktverlinken. Nach dem ersten Drittel kommt die Überschrift "Looking at the Store Manager Controller code" (unter den Webseiten-Bildern). Nach der Initialisierung des DB-Kontextes (db, Klasse MusicStoreEntities) werden die Action-Methoden des Controllers vorgestellt. Die HTTP-Request-Methode und den Pfad der URL sieht man jeweils als Kommentar darüberstehen. Üblicherweise reicht eine Zeile Code, um sich seine Daten zu holen. Das nächste Interessante kommt bei "POST: /StoreManager/Create". Die Formulardaten werden von der ASP.NET-MVC-Infrastruktur aufbereitet, ein neues Album-Objekt erstellt und der Methode Create als Argument übergeben. Nach der hier nicht zu sehenden (weil ausgelagerten) Validitätsprüfung wird das album zu den anderen im Kontext hinzugefügt und das Kontext-Objekt (db) beauftragt, die Änderungen zu speichern. Viel verständlicher kann man es kaum machen. Edit und Delete sind ebenso einfach zu bekommen.

Dass da jede Menge Zeug im Hintergrund abläuft, ist nur von Vorteil, so kann man sich besser auf seine Geschäftslogik konzentrieren.

Ein Nutzer muss nicht wissen, wie er sich zu persistieren hat. Das schafft nur unnötige Abhängigkeiten zwischen dem User und der Datenbank.
Naja zwischen user und datenbank nicht wirklich wenn man es sinnvoll implementiert und die Zugriffe auf die Datenbank der Elternklasse überlässt.

Auch in der Elternklasse sorgt sowas dafür, dass Eigenschaften und Methoden sichtbar sind, die mit der Verwaltung und nichts mit den Daten selbst zu tun haben. Am besten ist, wenn das Datenobjekt von all dem Kram nichts mitbekommt. Unter C# nennt man das POCO - Plain Old C# Object (in Part 4 des verlinkten Tutorials sieht man, dass die Album-Klasse einfach nur sie selbst ist und nichts erbt.) Auf PHP angewendet kommt da kein seriöser Name zustande ...

dedlfix.