Hellihello Daniel,

Naja bei ORM-Ansatz würdest Du die Objekte aufbauen, als ob es keine Datenbank gäbe:

class Benutzer {
  String name;
  Gruppe gruppe;
  ...
}

class Gruppe {
  String name;
  Benutzer[] benutzer;
  ...
}

Wenn man dann orm.execute("from Bentzer where name='foo') ausführt, würde man ein Benutzer-Objekt erhalten. Je nach Konfiguration wurde da die Gruppe gleich mit geladen oder auch noch nicht.

Mh, das entspricht doch aber meiner Interfacemethode My_Model->read(). Der würde ich mitgeben $category und $id, und sie würde mir ein Locationobjekt oder Artistobjekt zurückgeben.

Der ORM manipuliert den Code der Klassen (jedenfalls macht das Hibernate für Java so), sodass, wenn man dann benutzer.getGruppe() oder gruppe.getGruppen() aufruft, das entsprechende SQL-Query ausgeführt wird, ohne dass man das selbst implementieren müsste.

Gut, diese Funktionalität ließe sich ja in der Rückgabeklasse einbauen.

Man kann also weitgehend so programmieren, als gäbe es gar keine DB.
Außerdem hat man eben diese Objekt-Query-Sprache, mit der man dennoch sehr effiziente Abfragen formulieren kann.

Genau. Ich (also Hybernate) könnte theoretisch im Hintergrund alle Objekt-Queries in XML-xpath-Abfragen umwandeln, das würde den Kontrollerteil überhaupt nicht beeinträchtigen. Nur so eine eigene Erfindung ist halt recht proprietär. Wobei man ja bei Hibernate abkupfern kann. PHPDoc entstand ja auch aus JavaDoc. Vermutlich sowieso nicht falsch, bei den Geschichten um OOP doch mal einen Blick auf/in Java zu werfen. Ich hatte mal ein Buch "Java ist eine Sprache" aber das kam dann leider abhanden dem Verleiher.

Naja, man weiß nicht genau, was für SQL-Queries entstehen. Wenn man z.B. ein Query bezüglich einer Schnittstelle oder abstrakten Klasse macht, kann es sein, dass da mehrere Subqueries für die Tabellen konkreter Klassen abgesetzt werden. Das kommt auch darauf an, wie die Vererbungshierarchie auf Tabellen abgebildet wird. Das ist etwas, was man dem Query nicht gleich ansieht, was man aber natürlich schon ungefähr wissen sollte, aber am Anfang eben nicht unbedingt weiß.

Genau, aber das ist doch die Implementation einer Schnittstelle, die dann bei Hibernate/Java an die Rückgabeobjekte gekoppelt ist. Was ja vermutlich schlau ist.

Ja, letzteres wäre der "übliche" Weg. Wobei der Code zur Verarbeitung von XML eigentlich nicht in den Modell-Klassen stehen sollte, sondern in einer Bibliothek, sodass man so etwas machen kann:

Model model = XMLSerialization->read(file);
Benutzer name = model.getBenutzer("name");
...
XMLSerialization->write(model, file);

Der Kohäsion wegen? Ich hätte nun gedacht, der Kontroller spricht nur mit dem Model. Model::init() oder new Model("location"). Ob dann Model noch eine Helferklasse bräuchte, daran hatte ich nicht gedacht. Aber o.g. hast Du ja sicher nicht grundlos dahingeschrieben.

Die Modelklasse_n_ wissen im Idealfall nur, wie das Modell logisch aufgebaut ist. Das Abbilden zwischen Modell und XML übernimmt eine Bibliothek.

Mussichdrübernachdenken. Findet sich das so bei Hibernate auch. Anschauen immer besser als Nachdenken.

Da man bei Datenbanken dieses einmalige Auslesen und Speichern wegen der Datenmenge nicht machen kann, kann man da SQL in die Modellklassen packen, das ist aber wie gesagt auch nur eine Behelfslösung. Nach der "reinen Lehre" sollte ein Modell völlig unabhängig von der Speicherung sein.

Aber die orm-Klasse darf (;-).

Also zB. dass die Datei für "Benutzer" "BenutzerData.xml" heißt und im Ornder "data" liegt? Das muss der Controller ja nicht wissen, oder?
Richtig, diese Information liegt aber eigentlich ganz außerhalb der MVC-Klassen. Entweder hat man irgendwo noch einen Singleton rumfahren, der diesen Einstiegspunkt zur Verfügung stellt. Sowas in der Art:
Model model = Storage.getInstance().read();

Warum Singleton? Statische Klassen kennt Java auch? Storage.getInstance() soll ein Instanz der Storage-Klasse hergeben (Singleton, also "die eine" Instanz) und .read() gibt dann den Datenbankinhalt zurück? Model wäre demnach die komplette XML-Struktur/Baum?

Storage.getInstance().save(model);

Das Speichern übernimmt dann wieder die Storage-Klasse, indem ihr das zu speichernde Model übergeben wird.

Bei Desktopprogrammen muss der Controller auch oft wissen, wo die Daten gespeichert werden, da es sich bspw. um Dokumente handelt, die man mit dem Programm bearbeitet.

Aha, das kann er nicht vom Storage/Model erfragen Storage::whereAreMyFiles()?

Oder Single-Responsibility-Prinzip?
So könnte man es wohl auch nennen. "Coupling and Cohesion" sind die klassischen, akademischen Bezeichnungen und wurden 1974 von irgend welchen IBM-lern eingeführt oder so. Hat also erstmal nichts mit objektorientierung zu tun ;-)

De Marco 1975 - WikipediaDiskussion

http://de.wikipedia.org/wiki/GRASP,

... oder die Komponenten so unabhängig sind, dass es dazwischen ohnehin kaum Verknüpfungen gibt.

Das spielt wohl eine entscheidende Rolle.

Dank und Gruß,

frankx