nicht angemeldet
Hallo frankx,
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.
Ja, nur dass Du trennen kannst, zwischen der eigentlichen Abfrage und was dafür genau an SQL notwendig ist. Wenn Du nur SQL verwendest, musst Du entweder Deinem "My_Model" eine Methode für jedes Query hinzufügen, oder Du erlaubst dem Controller direkt Queries auszuführen, womit der Controller vom konkreten SQL-Dialekt (lässt sich evtl halbwegs in Grenzen halten, wenn man versucht nur Standard-SQL zu verwenden) abhängt und außerdem solche Dinge wie Queries über Schnittstellen nicht gehen. Dazu müsste der Controller ja wissen, welche Implementierungen es gibt und das hart in den Controller zu codieren ist natürlich ziemlich unflexibel.
Gut, diese Funktionalität ließe sich ja in der Rückgabeklasse einbauen.
Ja, wäre möglich.
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.
Ja, diesen Teil der ORM-Funktionalität kann man direkt in die Modell-Klassen hineinschreiben. Es ist eben eine recht aufwendige und auch langweilige Angelegenheit ;-)
Model model = XMLSerialization->read(file);
Benutzer name = model.getBenutzer("name");
...
XMLSerialization->write(model, file);Der Kohäsion wegen?
Nein, der Abstraktion von der Art der Serialisizerung bzw. von der Art des Modells.
Die Modellklassen beschreiben die Struktur, Beziehungen etc.
Die Serialisierungsschnittstelle (einen Standardbegriff gibt es dafür irgendwie nicht) implementiert das speichern und laden beliebiger Modelle.
Wenn ich XPath- oder SQL-Queries direkt in meinem Modell habe, dann binde ich damit das Modell ja an die Datenbank, den XMLParser etc. Außerdem muss ich das für jedes Modell neu machen.
Wenn ich eine Bibliothek habe, die Modelle auf Datenbanktabellen oder XML abbildet, kann ich diese für jedes Modell verwenden. Außerdem kann ich eine Instanz eines Modells in verschiedenen Resourcen abspeichern.
Es geht also sowas:
Transaction t = orm.begin();
Benutzer[] benutzer = t.select("form Benutzer");
benutzer.add(new Benutzer("foo"));
t.commit();
XMLSerializer.store("bar.xml", benutzer);
Damit könnte ich dann erreichen, dass der Benutzer "foo" der Datenbank hinzugefügt wurde und außerdem die Liste in eine XML-Datei gespeichert.
Jedenfalls vom Prinzip her, in der Praxis wird man wohl etwas aufpassen müssen, dass die XMLSerialisierung nicht irgend welche Daten abfragt, die man gar nicht serialisiert haben wollte oder sonstwas.
Aber o.g. hast Du ja sicher nicht grundlos dahingeschrieben.
Ja das Modell repräsentiert ja das, was in der Datenbank bzw in der Datei ist. Typischerweise muss man noch irgendwie die Resource repräsentieren und Operationen darauf. Bei Dateien ist das mit lesen und schreiben recht einfach, bei Datenbanken deutlich komplizierter.
Mussichdrübernachdenken. Findet sich das so bei Hibernate auch. Anschauen immer besser als Nachdenken.
Ja, Hibernate stellt wenig Bedingungen an das Modell, aber es wird beschrieben, wie man Modellklassen auf Datenbanken abbildet. Das könnte helfen.
Aber die orm-Klasse darf (;-).
Die tut das aber zur Laufzeit ;-)
Warum Singleton? Statische Klassen kennt Java auch?
Ja, statische Methoden gibt es natürlich auch. Würde auch gehen. Singletons erzeugen eben immer noch Objekte, die man auch so per Referenz weiter geben kann, dadurch muss man nicht gleich allen Code fest an die globale Information binden.
Storage.getInstance() soll ein Instanz der Storage-Klasse hergeben (Singleton, also "die eine" Instanz) und .read() gibt dann den Datenbankinhalt zurück?
Ja
Model wäre demnach die komplette XML-Struktur/Baum?
Model wäre ein logisches Objekt, die Klasse Storrage kapselt den Code, der irgend eine Konfigurationsdatei einliest, um festzustellen, wo die Daten liegen und dann diese irgendwie einliest. Das ist also eine Schnittstelle, die völlig davon abstrahiert, wo die Daten liegen und wie sie gespeichert sind.
Aha, das kann er nicht vom Storage/Model erfragen Storage::whereAreMyFiles()?
Naja, typischerweise muss man ja ein Dialog öffnen und den Benutzer fragen. Das öffnen irgend welcher Dialoge und das Aufrufen irgendwelcher Aktionen mit den Daten, die in diese Dialoge eingegeben wurden, ist ja typischerweise Aufgabe des Controllers. Streng genommen könnte man sagen, dass das Dateisystem mit zum Modell einer Desktopanwendung gehört.
De Marco 1975
Ach der, naja über das Thema kann man endlos philosophieren und es wurde auch getan und viele tun es immer noch ;-)
Hm, das scheint eine Mischung aus bekannten Konzepten zu sein.
Ein bisschen Coupling/Cohesion, Entwurfsmuster und MVC. Das entsprechende Buch ist erst von 2004. Vielleicht ist es eine schlüssige Gesamtdarstellung oder es ist nur ein neuer Aufguss alter Konzepte. In diesem Bereich gibt es sehr viel von Letzerem ;-)
Grüße
Daniel