[ORM] Lazy Loading - Wie implementieren?

[mquadrat]

Interface.. logisch..


EDIT: Was mich an der Live-Binding Doku ärgert? Sie ist praktisch nicht existent

[Meflin]

Zitat von mquadrat:

Interface.. logisch..

Ich weiß nicht was mit Delphi möglich ist, NHibernate, mit dem ich gerade arbeite, implementiert die Proxies als zur Laufzeit erzeugte Ableitung der Entity.

Ach und weil du Konfiguration über XML erwähnt hast: Wer will das machen?? Automapping FTW, nur so als Denkanstoß

[mquadrat]

@NamenLozer

Besser ist es IMHO, wenn der ORM keinen Code vorgenerieren muss, bzw. ich beliebige Klassen persistieren kann, von denen der ORM vorher noch gar nichts wusste.


@Meflin

Gute Frage. Mit dem Thema Code dynamisch zur Lautzeit erstellen habe ich mich bislang noch nicht befasst gehabt.

Automapping? Das funktioniert aber doch nur wenn

• die Spaltennamen identisch oder zumindest ableitbar sind (Bei SAP sind z.B. alle Spaltennamen 5-stellig.. nicht wirklich sprechende Namen)
• die Datentypen identisch oder ableitbar sind (Was ist wenn die Geschäftslogik mehr Typen kennt als die DB, also kein 1:1 Mapping möglich ist?)
• keine weiteren Metadaten verwendet werden sollen (Ich würde das - auch wenn man sich drüber streiten kann in welcher Ebene validiert werden soll - mit Validierungsinfos anreichern).

EDIT: Ich würde das Mapping sowieso abstrahieren. Ob das dann aus einer XML, aus Attributen oder aus einem Automapping kommt kann sich ja dann jeder aussuchen

[Meflin]

Zitat von mquadrat:

Automapping? Das funktioniert aber doch nur wenn...

OK, ich ging davon aus, man baut ein neues System. Anders sieht es vielleicht aus, wenn die Datenbank samt Daten schon existiert und ein neuer Client dafür entwickelt werden soll. Hier muss man vielleicht mehr manuell konfigurieren. In ersterem Fall will ich ja aber eigentlich nur die Ausnahmen der Regel konfigurieren, und nicht prinzipiell jedes einzelne Mapping. Das Mapping austauschbar zu machen ist daher ein sehr begrüßenswerter Schritt

Zum Thema Automapping: Ich finde das sehr elegant, wie Fluent NHIbernate das löst. Einerseits gibt es hier Conventions, die man einfach als Klasse implementieren kann (z.B. kann man darüber Tabellen/Spalten/Fremdschlüsselnamen etc generieren). Andererseits kann man glaube ich zumindest einzelne properties trotzdem manuell überschreiben (auch wenn ich das noch nie gemacht habe).

NHibernate an sich zu verwenden kam für uns jedenfalls aufgrund des XML-Overheads absolut nicht in Frage, deshalb dann Fluent NHibernate, welches ich dir als Anregungsimplementation größtenteils sehr empfehlen kann

[mquadrat]

Mal schauen, vielleicht wird ja aus dem "In-House-Projekt" mal ein ausgewachsener ORM. Aktuell evaluiere ich ja eh erst mal, ob ich was passendes finde oder eben selber was schreiben muss. Das Lazy Loading hat mich jetzt vor allem mal konzeptionell interessiert.

[Elvis]

Proxies von Interfaces scheinen mir hier am sinnvollsten zu sein.

Mir fallen da spontan ein paar Wege ein:

• TVirtualInterface
  In XE2 kam die Klasse TVirtualInterface hinzu. Die sollte dir schonmal einen Ansatz geben, um zur Laufzeit eine Implementierung eines Interfaces zu erzeugen.
  Was in Delphi halt immer noch komplett bescheuert (höflich ausgedrückt) ist, ist, dass man immer noch ewig viel hässlichen Code tippen muss, nur um eine dumme Property in ein Interface zu kriegen.
  Du musst also immer noch komplett hirnlose Getter/Setter schreiben und die Property selbst auch noch.
  Gibt aber schlimmeres denke ich mal.
  Collection-Properties würdest du initialisieren, da bräuchte man dann nur einen Getter,
  Als zugrundeliegenden Store für die Properties könntest du ein Dictionary und TValue nehmen.
• Maschinencode zur Laufzeit erzeugen
  Wenn du die TVirtualInterface-Lösung am Laufen hast, kannst du ja versuchen tatsächliche Klassen zur Laufzeit zu erzeugen.
  Aber ohne IL/Byte-Code ist das gleich mal 100-mal aufwendiger und instabiler. In IL gibt es eine Exception, wenn der IL Code nicht verifiziert, in native Delphi schreibst du fröhlich irgendwas irgendwohin und 10 Minuten später knallt es an einer ganz anderen Stelle.
  Nur mit so einem Runtime-Codegen könntest du auch dynamisch Proxies für Klassen erzeugen.
• Automatisch erzeugte Proxies zur Compilezeit
  Ein einfacherer Weg wäre es wohl, wenn du es zur Pflicht machst, dass dein Modell in einem Package liegt.
  Dann könntest du dieses im Post-Build laden, die Typen finden und nun relativ einfach die Proxies als Delphi Code erzeugen.
  Die fertige App muss ja deshalb noch lange keine Runtime-Packages benötigen, wäre also keine so schlimme Einschränkung.
  Der erzeugte Code müsste dann nur irgendwo so registriert werden, dass dein ORM weiß, wie er zur Laufzeit die Proxies finden kann.
  Das hier würde es auch ermöglichen, Klassen anstatt Interfaces für das Modell nehmen zu können.
  Denn zirkuläre Bezüge bringen das autom. Referenzzählen immer durcheinander, und ein Modell ohne die Möglichkeit den Graph hoch & runter zu navigieren ist bekanntlich grauenvoll.

btw: Ich weiß nicht wieweit tiOpf ist. In meinen alten Delphi-Tagen fand ich es immer ein wenig zu einschränkend und creepy. Aber das muss ja gar nicht mehr so sein.
Damit hättest du das Thema ORM/OPF abgehakt.

[mjustin]

Zitat von Meflin:

NHibernate an sich zu verwenden kam für uns jedenfalls aufgrund des XML-Overheads absolut nicht in Frage, deshalb dann Fluent NHibernate, welches ich dir als Anregungsimplementation größtenteils sehr empfehlen kann

Den XML "Overhead" kann man aber nach meiner Erfahrung zumindest in den Java Hibernate Versionen gut nutzen, um aus den HBM (Hibernate Mapping) Dateien, die man sich entweder automatisch per Hibernate Tool aus den Datenbankmetadaten erzeugt oder manuell erstellt, automatisch Delphi Quelltext für die Datenklassen zu erzeugen.

Unter http://hbm2pascal.appspot.com/ habe ich eine Online-Anwendung dafür, der Delphicode wird dynamisch aus den HBM Daten erzeugt. Wenn es für Delphi einmal gutes Templatig System geben sollte, lässt es sich das hbm2pascal Tool auch komplett in Delphi bauen.

Haken ist allerdings, dass XML für die Definition der Tabellen / Felder / Referentiellen Integritäten verwendet wird. Doch wenn man DB-Werkzeuge wie IBExpert & Co. hat, lässt sich über deren Editor ja auch bequem arbeiten und anschliessend läßt man DDL2HBM drüber laufen.

[neo4a]

Zitat von Meflin:

dann Fluent NHibernate, welches ich dir als Anregungsimplementation größtenteils sehr empfehlen kann

In der Delphi-Praxis sind Konzepte aus der Java-Welt viel zu oft nur virtual;abstract; Selbst wenn die Konzepte überzeugen, wird eine Implentierung leider häufig auch durch die speziellen Delphi-Gegebenheiten beschränkt.

Soweit ich das beurteilen kann, findet sich bei unseren französischen Kollegen eine funktionierende Delphi-Implementierung dieses Fluent- NHibernate- ORM- Ansatzes. Der "spiritus rector" hat für meinen Geschmack ein wenig zu lange für das französische Militär gearbeitet: Wenn man den Formalismus aus seiner 600-Seiten Dok. entfernt, bleiben ca. 50 Seiten Substanz, die dann aber sehr interessant sind.

Nicht nur dasLazy Loading verlangt von dem Entwickler ein hohes Maß an Vertrauen (die Quelle spricht u.a. von Pest und Cholera) in das Framework und seine Leistungsfähigkeit. Die zugrunde liegende Implementierung erscheint mir jedenfalls immer sehr komplex und durch Formalismen aufgebläht, so dass mir in der täglichen Praxis der direkte Weg irgendwie "sicherer" erscheint (und ich mich trotzdem damit nicht wohler fühle).

[mquadrat]

Ist ja doch noch eine muntere Diskussion geworden

Ich werde bei Gelegenheit mal einige der existierenden ORMs anschauen.

[generic]

In Delphi XE wurde der TVirtualMethodInterceptor eingeführt.
Da drüber würde sich auch sehr einfach was basteln lassen.