LINQ ORM Delphi (TMS / Devart)

[MyRealName]

Beim Aurelius musst Du aufpassen, ob Du datenbank transaktionen brauchst. Das hat da kein gutes Modell. Ich hatte eine längere Diskussion mit Wagner Landgraf (dem Programmierer von Aurelius) und hab ihm erklärt dass sein augenblickliches Modell es nicht zulässt, 2 Instanzen vom gleichen Object zu erstellen, jedes mit eigenem ObjectManager und dann getrennt commit oder rollback zu machen. Bei Aurelius (Stand Version 3.3) ist es so, dass es global nur eine Transaction gibt (ich nutze UniDAC), die von der TUniConnection selbst kommt. Das heisst dann aber auch, dass wenn ich Commit in einem Fenster mache, er auch die Daten von Fenster 2 committed.

Seine Lösung war eine neue DbVerbindung für jedes Fenser.

Also ein kleieres Projekt machte ich damit, das geht sehr gut, dort nutze ich aber nur sehr begrenzt und sequentiell das Schreiben der Daten in die Db.

[sakura]

Um mal noch ein interessantes Projekt zu nennen: mORMot - Super Doku, allerdings eine gewissen Einarbeitungszeit ist schon nötig.

......

[mkinzler]

Oder MarshMallow (nun Teil von Spring4D).

[Stevie]

Zitat von mkinzler:

Oder MarshMallow (nun Teil von Spring4D).

Würd ich nur bedingt zu raten, da ich Entwicklung dieses Teils erstmal auf Eis lege.

[WiPhi]

Zitat von Stevie:

Würd ich nur bedingt zu raten, da ich Entwicklung dieses Teils erstmal auf Eis lege.

Könnte man dann nicht das Spring.Nullable aus der großen Spring-Unit in eine eigene Unit verlagern, um Konflike mit ORM Nullables (wie Aurelius) zu vermeiden? s. https://www.delphipraxis.net/199250-...-nullable.html

Generell finde ich aber, dass man die beiden Frameworks sehr gut miteinander kombinieren kann. Bis jetzt war das größte Problem nur das Nullable.

[mkinzler]

Zitat von Stevie:

Zitat von mkinzler:

Oder MarshMallow (nun Teil von Spring4D).

Würd ich nur bedingt zu raten, da ich Entwicklung dieses Teils erstmal auf Eis lege.

Schade

[Union]

Ja, mOrmot hat eine steile Lernkurve. Dafür ist es aber auch wirklich umfassend. Leider läuft auch die interne Kommunikation C/S mit JSON. Daher eher für echte Multi-Tier Anwendungen geeignet. Vorteil: Es ist zu jeder Delphi-Version kompatibel. Nachteil: Es ist zu jeder Delphi-Version kompatibel.
Basiert daher zwingend auf Vererbung und eigenen Datentypen.

[sakura]

Zitat von Union:

Leider läuft auch die interne Kommunikation C/S mit JSON. Daher eher für echte Multi-Tier Anwendungen geeignet.

Wieso sollte das nicht gehen? Wir nutzen es genau so, mit hunderten Clients ohne Probleme.

......

[Schokohase]

Zitat von MyRealName:

Seine Lösung war eine neue DbVerbindung für jedes Fenser.

Die richtige Lösung heißt eigentlich pro ObjectManager eine eigene DbVerbindung und für jeden Kontext einen eigenen ObjectManager

[MyRealName]

Zitat von Schokohase:

Zitat von MyRealName:

Seine Lösung war eine neue DbVerbindung für jedes Fenser.

Die richtige Lösung heißt eigentlich pro ObjectManager eine eigene DbVerbindung und für jeden Kontext einen eigenen ObjectManager

Naja, jedes Fenster hatte in meinem Beispiel innerhalb dieser Diskussion einen eigenen ObjectManager. Aber da es eine MDI Anwendung ist im Netz, die von jedem Fenstertyp soviele Instanzen erstellen kann wie man wll, ist dies keien akzeptale Lösung, IMHO, da dies zu hunderten von Verbindungen führt. Besser wäre eine Transaction-Lösung, wo man eine DbVerbindung hat und jeder ObjectManager eine eigene Transaction besitzt.