LINQ ORM Delphi (TMS / Devart)

[taveuni]

Hallo zusammen,

In Kürze beginnen wir ein grösseres Projekt welches in Delphi umgesetzt werden muss. Von Visualstudio .Net bin ich mir mittlerweile einige Annehmlichkeiten gewohnt. Wie z.B. das SQL Gefrickel im Code zu vermeiden. Frage: Hat jemand Erfahrung mit einem ORM wie Devart, TMS Aurelius oder anderen und kann eine Empfehlung abgeben?

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

[haentschman]

Hallöle...

Zitat:

Wie z.B. das SQL Gefrickel im Code zu vermeiden

Dazu braucht es nicht umbedingt ein ORM. Ich verwende eine andere Strategie. Es gibt für jedes DBMS was benutzt wird, ein Interface. Der komplette Zugang zur DB ist in diesem Interface gekapselt. Im Interface werden dann die Ergebnisse der SQL Abfragen in Objekte gewandelt. Die Anwendung kennt eigentlich keine Datenbank. Die Daten könnten auch aus Oma´s Küchenschrank kommen. Dann sage ich nur in der Anwendung (Aufruf procedure im Interface)... "Fülle mir mal die Liste mit den Mitarbeitern". Am Ende habe ich eine TObjectList<TMitarbeiter>...fertsch. Nachteil: Man verzichtet hoffentlich auf datensensitive Controls...denn da funktioniert das nicht. :stupid:
Zum SQL Gefrickel:
[Meine Lösung]
Meine Statements liegen in einer Ordnerstruktur. Das bedeutet, die Statements sind ausführbar im Editor. Diese Struktur wird als Ressource einkompiliert. Das Interface holt sich die SQL aus der Ressource entsprechend des DBMS. In den Proceduren gibt es nur den Namensaufruf und die Zuordnung der Parameter...fertsch

Delphi-Quellcode:

function TBlubbDatabase.GetSQLByName(SQLName: string): string;
var
  SQLStream: TResourceStream;
  SQLStrings: TStringList;
  SQLStringsDecrypt: TStringList;
begin
  Result := '';
  SQLStrings := TStringList.Create;
  try
    SQLStringsDecrypt := TStringList.Create;
    try
      SQLStream := TResourceStream.Create(HInstance, SQLName, PWideChar(conDatabaseResourceGroupString));
      try
        try
          SQLStrings.LoadFromStream(SQLStream);
          SQLStringsDecrypt.Text := TBlubbToolsCrypt.Decrypt(SQLStrings.Text, conKey); //Verschlüsselung wenn nötig 
          SQLStringsDecrypt.Delete(0); // Kommentar entfernen
          Result := SQLStringsDecrypt.Text;
        except
          Result := '';
        end;
      finally
        SQLStream.Free;
      end;
    finally
      SQLStringsDecrypt.Free;
    end;
  finally
    SQLStrings.Free;
  end;
end;

Delphi-Quellcode:

procedure TBlubbDatabase.FillList(List: TBlubbFieldList; TableName: string);
var
  I: Integer;
  Qry: TFDQuery;
  Field: TBlubbField;
begin
  Qry := CreateQuery;
  try
    Qry.SQL.Text := Format(GetSQLByName('BLUBB_TABLE_FIELDLIST'), [TableName]);
    Qry.Open;
    if not Qry.Eof then
    begin
      List.Clear;
      for I := 0 to Qry.Fields.Count - 1 do
      begin
        Field := TBlubbField.Create;
        Field.FieldIndex := I;
        Field.FieldName := Qry.Fields[I].FieldName;
        Field.Fieldype := Qry.Fields[I].DataType;
        List.Add(Field);
      end;
    end;
  finally
    Qry.Free;
  end;
end;

[taveuni]

Zitat:

Zitat von Union (Beitrag 1426976)

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?

[taveuni]

Zitat:

Zitat von haentschman (Beitrag 1426979)

(..)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.

[Schokohase]

Zitat:

Zitat von taveuni (Beitrag 1426986)

Zitat:

Zitat von Union (Beitrag 1426976)

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:

Zitat von taveuni (Beitrag 1426987)

Zitat:

Zitat von haentschman (Beitrag 1426979)

(..)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. :roll:

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.

...:cat:...

[mkinzler]

Oder MarshMallow (nun Teil von Spring4D).

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