AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken LINQ ORM Delphi (TMS / Devart)

LINQ ORM Delphi (TMS / Devart)

Ein Thema von taveuni · begonnen am 5. Mär 2019 · letzter Beitrag vom 13. Mär 2019
Antwort Antwort
Seite 1 von 3  1 23   
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
404 Beiträge
 
Delphi 10.3 Rio
 
#1

LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 07:31
Datenbank: MSSQL • Version: Egal • Zugriff über: LINQ
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?
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
Benutzerbild von Union
Union

Registriert seit: 18. Mär 2004
Ort: Luxembourg
3.292 Beiträge
 
Delphi 7 Enterprise
 
#2

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 11:18
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.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
4.227 Beiträge
 
Delphi 10.1 Berlin Professional
 
#3

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 11:44
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.
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;
  Mit Zitat antworten Zitat
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
404 Beiträge
 
Delphi 10.3 Rio
 
#4

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 13:01
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?
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
404 Beiträge
 
Delphi 10.3 Rio
 
#5

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 13:06
(..)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.
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
Schokohase
Online

Registriert seit: 17. Apr 2018
972 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#6

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 13:19
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).

(..)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
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Santa Marta / Colombia
378 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#7

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 13:33
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.
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: München
11.486 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#8

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 14:10
Um mal noch ein interessantes Projekt zu nennen: mORMot - Super Doku, allerdings eine gewissen Einarbeitungszeit ist schon nötig.

......
Daniel W.
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.434 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#9

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 14:14
Oder MarshMallow (nun Teil von Spring4D).
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Union
Union

Registriert seit: 18. Mär 2004
Ort: Luxembourg
3.292 Beiträge
 
Delphi 7 Enterprise
 
#10

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 14:15
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.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:11 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf