LINQ ORM Delphi (TMS / Devart)

[taveuni]

Zitat von Union:

Ich arbeite seit ein paar Jahren mit Aurelius. Erspart einem eine Menge SQL Gefummel und hilft so Fehler zu vermeiden. Allerdings sind die Datenmengen die da geschaufelt werden in der realen Welt nicht unerheblich. Dann muss man mit spezifischen Modellen arbeiten oder doch wieder manuell mit SQL arbeiten.

Wie meinst Du das? Bezüglich Performance?

[Schokohase]

Zitat von taveuni:

Zitat von Union:

Ich arbeite seit ein paar Jahren mit Aurelius. Erspart einem eine Menge SQL Gefummel und hilft so Fehler zu vermeiden. Allerdings sind die Datenmengen die da geschaufelt werden in der realen Welt nicht unerheblich. Dann muss man mit spezifischen Modellen arbeiten oder doch wieder manuell mit SQL arbeiten.

Wie meinst Du das? Bezüglich Performance?

Ja, es gibt bei .Net auch eine Vielzahl die EF eher meiden und z.B. Dapper verwenden, weil man hier noch Einfluß auf den SQL-Code hat (Performance).

Zitat von taveuni:

Zitat von haentschman:

(..)Ich verwende eine andere Strategie.(..)

Ja. Das habe ich auch gemacht in früheren Delphi Projekten. Wenn Du aber ein paar Jahre mit EntityFrameworks wie in .Net Visualstudio enthalten gearbeitet hast....
Es kann so einfach sein. Code First oder Database First. Und dann alles per LINQ. Ist schon eine andere Nummer bezüglich Übersichtlichkeit und Anwendung.

Kann es sein, dass du diese Entity-Modelle auch im Business-Layer verwendest? Das wäre bei mir ein NoGo, denn die gehören ausschließlich dem Persistence-Layer

[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.

......