[Tutorial] Laden / Speichern von Objekten in einer normalisierten Datenbank

[haentschman Online]

Hallo...

Das ist mein erstes Tutorial. Bitte seid gnädig... Es soll als Anregung dienen wie man auch ohne datensensitive Controls auskommt.

Ich möchte Euch zeigen, wie man programmintern mit Objekten arbeitet und diese Objekte in einer normalisierten Datenbank speichert. Im Prinzip ist es
ein Mini-ORM ohne externes Framework. Der Kreativität sind keine Grenzen gesetzt.
Ich habe versucht das einfach zu halten. Mancher Code könnte mit unterschiedlichen Methoden realisiert werden. (JOIN statt separater procedure) Welche Variante
man nimmt, ist jedem selbst überlassen.

Hinweise:
* Weil die Units zu lang sind... siehe Projekt.
* Weil nicht alle das compilieren können ist die EXE zum Ausprobieren dabei... siehe Projekt
* Die Zwischenvariablen (wie var Customer: TCustomer; in Main) sind nicht immer notwendig aber es macht es für den Anfang imho übersichtlicher.

Anhänge:
* Projekt mit Datenbank ausführbar.
* kompletter Quelltext D10.1

Voraussetzungen:
Delphi XE und höher wegen Generics im Beispiel

Aufbau 3 Schicht Anwendung:
(Unit: FormMain) -> (Unit: Logic) -> (Unit: Database) -> (Database: z.B.Firebird)
<- (Event) <- (Event)

Database (beliebiebiges DBMS)

Code:

CREATE TABLE T_CUSTOMER (
    ID                INTEGER NOT NULL,
    F_NAME            VARCHAR(50),
    F_FIRST_NAME      VARCHAR(50),
    F_ADDRESS_ID      INTEGER
);


CREATE TABLE T_ADDRESS (
    ID                 INTEGER NOT NULL,
    F_POSTCODE         VARCHAR(30),
    F_TOWN             VARCHAR(50),
    F_STREET           VARCHAR(50),
    F_HOUSE_NUMBER     VARCHAR(10)
);

Unit: Database
In dieser Unit ist die Schnittstelle zur Datenbank definiert. In diesem Falle als Interface. Die Logik kennt nur das Interface welches in der Logik instanziert wird. (siehe Unit: Logik)
Die Querys werden nicht mehr auf die Form "geklatscht" und dort die SQL eingetragen. Das Interface kennt alleinig die SQL Statements.
Das macht es einfacher mehrere Datenbanken anzubinden. Für jede Datenbank gibt es dann ein eigenes Interface wegen der Unterschiede der möglichen Datenbanken.
Als Datenbankkomponenten kommen hier die UniDAC mit der Schnittstelle zu Firebird zum Einsatz. Andere Komponenten sind natürlich auch möglich.
Diese eine Unit kennt allein die Datenbank. Die Kommunikation mit der Logik, welche die Unit nicht kennt, kann sowohl über Events oder als Rückgabe der Funktion
aus der Logik erfolgen.

Interface:

Delphi-Quellcode:

unit Database.Interfaces;

interface

uses
  Logic.DataClasses,
  Database.Events;

type
  IDatabaseCommon = interface(IInterface) // ggf. in seperate Unit bei mehreren DBMS
  ['{E41ADEE8-56F9-4223-8238-61B6C033DFF1}']
    function GetAfterConnect: TOnAfterConnectEvent;
    procedure SetAfterConnect(const Value: TOnAfterConnectEvent);
    function GetDatabaseError: TOnDatabaseErrorEvent;
    procedure SetDatabaseError(const Value: TOnDatabaseErrorEvent);
    function GetAfterDisconnect: TOnAfterDisconnectEvent;
    procedure SetAfterDisconnect(const Value: TOnAfterDisconnectEvent);

    property OnAfterConnect: TOnAfterConnectEvent read GetAfterConnect write SetAfterConnect;
    property OnAfterDisconnect: TOnAfterDisconnectEvent read GetAfterDisconnect write SetAfterDisconnect;
    property OnDatabaseError: TOnDatabaseErrorEvent read GetDatabaseError write SetDatabaseError;

    function Connect: Boolean;
    procedure Disconnect;
    procedure StartTransaction;
    procedure Commit;
    procedure Rollback;

    function GetSQLByName(SQLName: string): string; // ggf. bei Laden des SQL Statements aus Ressource
  end;

  IDatabase = interface(IDatabaseCommon)
    ['{C1BC6FE3-9586-4D92-8221-A3DD030E80B5}']
    // Entweder overload oder als einzelne Prozeduren, der Creativität sind keine Grenzen gesetzt.
    procedure FillList(List: TCustomerList); overload;

    function Save(Customer: TCustomer): Integer; overload;
    function Save(Address: TAddress): Integer; overload;

    procedure Get(Customer: TCustomer; ID: Integer); overload;
    procedure Get(Address: TAddress; ID: Integer); overload; // kann auch separat genutzt werden...oder auch nicht
  end;


implementation

end.

Database gekürzt:

Delphi-Quellcode:

unit Database.Firebird;

interface

uses
  System.Classes, System.SysUtils, System.Variants, System.Generics.Collections, System.Generics.Defaults, System.DateUtils,
  Uni, DBAccess, InterBaseUniProvider,
  Database.Interfaces, Database.Events,
  Logic.DataClasses;

type
  TDatabaseFirebird = class(TInterfacedObject, IDatabase)
  strict private
    // Properties Connection
    FConnection: TUniConnection;
    FOnAfterConnect: TOnAfterConnectEvent;
    FOnAfterDisconnect: TOnAfterDisconnectEvent;
    FOnDatabaseError: TOnDatabaseErrorEvent;
    // Getter / Setter
    function GetAfterConnect: TOnAfterConnectEvent;
    procedure SetAfterConnect(const Value: TOnAfterConnectEvent);
    function GetDatabaseError: TOnDatabaseErrorEvent;
    procedure SetDatabaseError(const Value: TOnDatabaseErrorEvent);
    function GetAfterDisconnect: TOnAfterDisconnectEvent;
    procedure SetAfterDisconnect(const Value: TOnAfterDisconnectEvent);
    // Eventhandler
    procedure DoAfterConnect(Sender: TObject);
    procedure DoAfterDisconnect(Sender: TObject);
    procedure DoError(Sender: TObject; E: EDAError; var Fail: Boolean);
    // Funktionen
    function CreateQuery: TUniQuery;
  public
    constructor Create;
    destructor Destroy; override;
    // Events
    property OnAfterConnect: TOnAfterConnectEvent read GetAfterConnect write SetAfterConnect;
    property OnAfterDisconnect: TOnAfterDisconnectEvent read GetAfterDisconnect write SetAfterDisconnect;
    property OnDatabaseError: TOnDatabaseErrorEvent read GetDatabaseError write SetDatabaseError;
    // Funktionen aus Interface
    function Connect: Boolean;
    procedure Disconnect;
    procedure StartTransaction;
    procedure Commit;
    procedure Rollback;

    function GetSQLByName(SQLName: string): string; // ggf. bei Laden des SQL Statements aus Ressource

    procedure FillList(List: TCustomerList); overload;

    function Save(Customer: TCustomer): Integer; overload;
    function Save(Address: TAddress): Integer; overload;

    procedure Get(Customer: TCustomer; ID: Integer); overload;
    procedure Get(Address: TAddress; ID: Integer); overload; // kann auch separat genutzt werden...oder auch nicht
  end;
  
...

Unit: Logic
In dieser Unit ist die Logik definiert. Die Logik nimmt die Befehle der Form entgegen und führt diese aus. Desweiteren hällt die Logik die Daten der Anwendung. In diesem
Falle die CustomerList. Die Kommunikation mit der Form, welche die Unit nicht kennt, kann sowohl über Events oder als Rückgabe der Function aus der Logik erfolgen.

Klassendefinition gekürzt:

Delphi-Quellcode:

unit Logic.DataClasses;

interface

uses
  System.Generics.Collections, System.Generics.Defaults;

type
  TDataState = (ddsNormal, ddsNew, ddsModified, ddsDeleted);

  TBaseClass = class
  strict protected
    FID: Integer;
    FState: TDataState; // jedes Objekt kennt seinen Status
  public
    property ID: Integer read FID write FID;
    property State: TDataState read FState write FState;
  end;

  TAddress = class(TBaseClass)
  strict private
    FTown: string;
    FStreet: string;
    FPostCode: string;
    FHouseNumber: string;
  public
    constructor Create;
    destructor Destroy; override;
    property PostCode: string read FPostCode write FPostCode;
    property Town: string read FTown write FTown;
    property Street: string read FStreet write FStreet;
    property HouseNumber: string read FHouseNumber write FHouseNumber;
  end;

  TCustomer = class(TBaseClass)
  strict private
    FName: string;
    FAddress: TAddress;
    FFirstName: string;
  public
    constructor Create;
    destructor Destroy; override;
    property Name: string read FName write FName;
    property FirstName: string read FFirstName write FFirstName;
    property Address: TAddress read FAddress write FAddress;
  end;

  TCustomerList = TObjectList<TCustomer>;
...

Logic gekürzt:

Delphi-Quellcode:

unit Logic.Base;

interface

uses
  Database.Interfaces, Database.Firebird, Database.Events,
  Logic.DataClasses;

type
  TOnFillCustomerListEvent = procedure(Sender: TObject; List: TCustomerList) of object;
  TOnGetCustomerEvent = procedure(Sender: TObject; Customer: TCustomer) of object;
  TOnDataChangedEvent = procedure(Sender: TObject; State: Boolean) of object;

  TLogic = class
  strict private
    FDatabase: IDatabase;
    FCustomerList: TCustomerList;

    FOnConnectDatabase: TOnAfterConnectEvent;
    FOnDisconnectDatabase: TOnAfterDisconnectEvent;
    FOnDatabaseError: TOnDatabaseErrorEvent;
    FOnFillCustomerList: TOnFillCustomerListEvent;
    FOnGetCustomer: TOnGetCustomerEvent;

    procedure DoOnDatabaseError(Sender: TObject; ErrorNumber: Integer; ErrorMessage: string);
    procedure DoOnAfterConnect(Sender: TObject);
    procedure DoOnAfterDisconnect(Sender: TObject);
  private
    FDataChanged: Boolean;
    FOnDataChanged: TOnDataChangedEvent;
    procedure SetDataChanged(const Value: Boolean);
  public
    constructor Create;
    destructor Destroy; override;

    property OnConnectDatabase: TOnAfterConnectEvent read FOnConnectDatabase write FOnConnectDatabase;
    property OnDisconnectDatabase: TOnAfterDisconnectEvent read FOnDisconnectDatabase write FOnDisconnectDatabase;
    property OnDatabaseError: TOnDatabaseErrorEvent read FOnDatabaseError write FOnDatabaseError;
    property OnFillCustomerList: TOnFillCustomerListEvent read FOnFillCustomerList write FOnFillCustomerList;
    property OnGetCustomer: TOnGetCustomerEvent read FOnGetCustomer write FOnGetCustomer;
    property OnDataChanged: TOnDataChangedEvent read FOnDataChanged write FOnDataChanged;

    property DataChanged: Boolean read FDataChanged write SetDataChanged;

    property CustomerList: TCustomerList read FCustomerList;

    procedure GetCustomerList;
    procedure GetCustomer(ID: Integer);
    procedure SaveCustomer(Customer: TCustomer);
    procedure RefreshCustomerList;
  end;
...

Unit: FormMain gekürzt
In dieser Unit ist die Form mit den Controls definiert. Die Form gibt der Logic Befehle was sie an Informationen haben möchte. Über Events werden die Information aus der Logik
zurückgeliefert und verarbeitet.

Delphi-Quellcode:

unit FormMain;

interface

uses
  Winapi.Windows, Winapi.Messages,
  System.SysUtils, System.Variants, System.Actions, System.Classes,
  Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.ExtCtrls, Vcl.StdCtrls, Vcl.ActnList, Vcl.ComCtrls,
  ImageList.Small,
  Logic.Base, Logic.DataClasses;

const
  conTextGroupboxNormal = 'Details (Normal)';
  conTextGroupboxEdit = 'Details (Editmodus)';

type
  TfoMain = class(TForm)
    pnlTop: TPanel;
    pnlContent: TPanel;
    lvCustomers: TListView;
    btnNew: TButton;
    btnCopy: TButton;
    btnDelete: TButton;
    grpDetails: TGroupBox;
    btnSave: TButton;
    edtName: TEdit;
    lblName: TLabel;
    edtFirstName: TEdit;
    lblFirstName: TLabel;
    edtPostCode: TEdit;
    lblPostCode: TLabel;
    edtTown: TEdit;
    lblTown: TLabel;
    edtStreet: TEdit;
    lblStreet: TLabel;
    edtHouseNumber: TEdit;
    lblHouseNumber: TLabel;
    actlstMain: TActionList;
    actNew: TAction;
    btnInfo: TButton;
    actCopy: TAction;
    actDelete: TAction;
    actInfo: TAction;
    actSave: TAction;
    actCancel: TAction;
    btnCancel: TButton;
    btnMessage: TButton;
    actMessage: TAction;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure FormShow(Sender: TObject);
    procedure actNewExecute(Sender: TObject);
    procedure actCopyExecute(Sender: TObject);
    procedure actDeleteExecute(Sender: TObject);
    procedure actInfoExecute(Sender: TObject);
    procedure actSaveExecute(Sender: TObject);
    procedure actCancelExecute(Sender: TObject);
    procedure lvCustomersChange(Sender: TObject; Item: TListItem; Change: TItemChange);
    procedure actMessageExecute(Sender: TObject);
  private
    FLogic: TLogic;
    procedure DoFillCustomerList(Sender: TObject; List: TCustomerList);
    procedure DoGetCustomer(Sender: TObject; Customer: TCustomer);
    procedure DoDataChanged(Sender: TObject; State: Boolean);

    procedure ShowCustomerList(List: TCustomerList);
    procedure ShowCustomer(Customer: TCustomer);
    procedure SetCustomerToEdit(Active: Boolean);
    procedure SetButtons(Active: Boolean);
  public

  end;

var
  foMain: TfoMain;
...

Prinzip des Datenholens:

Delphi-Quellcode:

procedure TDatabaseFirebird.Get(Customer: TCustomer; ID: Integer); // nur einen Customer holen
var
  Qry: TUniQuery;
begin
  Qry := CreateQuery; // Query incl. der Connection erzeugen
  try
    // SQL wie gehabt
    Qry.SQL.Text := 'SELECT * FROM T_CUSTOMER WHERE ID = :ID';
//  Alternativ über Ressource:  Qry.SQL.Text := GetSQLByName('xxx'); // SQL Name ergänzen
    Qry.ParamByName('ID').AsInteger := ID;
    Qry.Open;
    
    // das Objekt füllen
    Customer.ID := Qry.FieldByName('ID').AsInteger; 
    Customer.Name := Qry.FieldByName('F_NAME').AsString;
    Customer.FirstName := Qry.FieldByName('F_FIRST_NAME').AsString;
    // Alternative für GET wäre ein JOIN im Statement und die Adresse hier zusammenbauen.
    // Der Vorteil der Trennung: Man kann auch die Adresse seperat lesen. Wie man es braucht... :-)
    Get(Customer.Address, Qry.FieldByName('F_ADDRESS_ID').AsInteger);
    Customer.State := ddsNormal; // Wichtig: Status setzen
  finally
    Qry.Free;
  end;
end;

...

procedure TDatabaseFirebird.FillList(List: TCustomerList); // komplette Liste füllen
var
  Qry: TUniQuery;
  Customer: TCustomer;
begin
  List.Clear;
  Qry := CreateQuery; // Query incl. der Connection erzeugen
  try
    Qry.SQL.Text := 'SELECT * FROM T_CUSTOMER';
//  Alternativ über Ressource:  Qry.SQL.Text := GetSQLByName('xxx'); // SQL Name ergänzen
    Qry.Open;
    while not Qry.Eof do
    begin
      Customer := TCustomer.Create; // Objekt erzeuggen
      Get(Customer, Qry.FieldByName('ID').AsInteger); // Objekt füllen
      List.Add(Customer); // Objekt in Liste legen
      Qry.Next;
    end;
  finally
    Qry.Free;
  end;
end;

Prinzip der Speicherung

Delphi-Quellcode:

function TDatabaseFirebird.Save(Customer: TCustomer): Integer; // Speichern
var
  Qry: TUniQuery;
begin
  Result := -1;
  Qry := CreateQuery;
  try
    StartTransaction;
    try
      case Customer.State of // entsprechend dem Status des Objektes
        ddsNew: // insert
          begin
            Customer.Address.ID := Save(Customer.Address); // Rückgabe der ID als Erstes wegen ID
            Qry.SQL.Text := 'INSERT INTO T_CUSTOMER (F_NAME, F_FIRST_NAME, F_ADDRESS_ID) VALUES (:NAM, :FIN, :ADD) returning ID';
            //  Alternativ über Ressource:  Qry.SQL.Text := GetSQLByName('xxx'); // SQL Name ergänzen
            // das Objekt dem SQL übergeben
            Qry.ParamByName('NAM').AsString := Customer.Name;
            Qry.ParamByName('FIN').AsString := Customer.FirstName;
            Qry.ParamByName('ADD').AsInteger := Customer.Address.ID;
            Qry.ExecSQL;
            Customer.ID := Qry.ParamByName('RET_ID').AsInteger;

            Customer.State := ddsNormal;
            Result := Customer.ID;
          end;
        ddsModified: // update
          begin
            Qry.SQL.Text := 'UPDATE T_CUSTOMER SET F_NAME = :NAM, F_FIRST_NAME = :FIN, F_ADDRESS_ID = :ADD WHERE ID = :ID';
            //  Alternativ über Ressource:  Qry.SQL.Text := GetSQLByName('xxx'); // SQL Name ergänzen
            // das Objekt dem SQL übergeben
            Qry.ParamByName('ID').AsInteger := Customer.ID;
            Qry.ParamByName('NAM').AsString := Customer.Name;
            Qry.ParamByName('FIN').AsString := Customer.FirstName;
            Qry.ParamByName('ADD').AsInteger := Customer.Address.ID;
            Qry.ExecSQL;

            Save(Customer.Address);

            Customer.State := ddsNormal;
            Customer.Address.State := ddsNormal;
            Result := Customer.ID;
          end;
        ddsDeleted: // deleted
          begin
            Qry.SQL.Text := 'DELETE FROM T_CUSTOMER WHERE ID = :ID';
            //  Alternativ über Ressource:  Qry.SQL.Text := GetSQLByName('xxx'); // SQL Name ergänzen
            Qry.ParamByName('ID').AsInteger := Customer.ID;
            Qry.ExecSQL;

            Customer.Address.State := ddsDeleted;
            Save(Customer.Address);

            Result := Customer.ID;
          end;
      end;

      Commit;
    except
      Rollback;
    end;
  finally
    Qry.Free;
  end;
end;

Prinzip der Datenanzeige

Delphi-Quellcode:

procedure TfoMain.DoFillCustomerList(Sender: TObject; List: TCustomerList); // Event nach dem Datenholen
begin
  ShowCustomerList(List);
  SetCustomerToEdit(False);
end;

...

procedure TfoMain.ShowCustomerList(List: TCustomerList);
var
  Item: TListItem;
  Customer: TCustomer;
begin
  lvCustomers.Items.Clear;
  for Customer in List do
  begin
    Item:= lvCustomers.Items.Add;
    Item.Data:= Customer; // Das Objekt (Pointer) hängt an dem Eintrag
    Item.SubItems.Add(Customer.Name);
    Item.SubItems.Add(Customer.FirstName);
    Item.SubItems.Add(Customer.Address.Town);
    Item.ImageIndex:= dmSmall.GetIconIndexDataState(Customer.State);
  end;
  lvCustomers.Items.Item[0].Selected := True; // ersten Eintrag markieren...oder so
end;

Erweiterungen:
Nach Bedarf können u.a. Funktionen hinzugefügt oder mit einander kombiniert werden. (DRY)

Vorteile:
* Keine datensensitiven Controls. Das bedeutet Unabhängigkeit von der Optik der DB sensitiven Controls.
* Eine Property des Objektes kann z.B. in einem TEdit einem TMemo oder mit einem TRotMitGelbenPunktenControl dargestellt werden.
* Alle SQL Statements auf einem Fleck. Das erleichtert das Suchen nach einem Statement. Die SQL sind nicht mehr auf den gesamten QT verteilt.
* Die Umbauten bei Datenbankwechsel beziehen sich nur auf das Interface.
* Durch die Objekte kann man sich die Informationen beliebig zustammenstellen. Auch wenn sie auch verschieden Tabelle stammen.
* Speichern mit einem Einzeiler

Delphi-Quellcode:

FDatabase.Save(Customer);
...

* Objekte sind besser debugbar.
* Objekte können wiederum Listen mit Objekten enthalten.
* Objekte sind mit einem Rutsch, über das Database Interface, speicherbar.

Bei diesem Tutorial geht es ums Prinzip bei der Arbeit mit Objekten ohne die üblichen Verdächtigen der großen Frameworks für Datenbanken. Meistens lohnt der Aufwand nicht
ein großes Framework zu installieren. Auch der Einarbeitungsaufwand bei diesen ist nicht ohne... Manchmal ist weniger mehr.


Diskussion eröffnet.

PS: Alle Fehler sind urheberrechtlich geschützt weil Unikate.

[Rollo62]

Wieso nur gnädig, ich bin doch immer froh wenn sich einer die Zeit nimmt etwas genauer zu erklären

Ich frage mich bei dem ganzen ORM nur immer ob es der richtige Weg ist.
Datenbanken wurde noch gemacht um 1 bis 1Mio. Datensätze zu verwalten.
ORM mit Listen im Speicher (OK, ich lass man das intelligente Speicherverwalten weg),
das läuft doch bei 1 Mio. Datensätze in eine Krise.

Dann die Anbindung der Daten an die Controls.
Im Prinzip bin ich ja voll dafür, also heist die Richtung LiveBinding,
nur leider funktioniert das nur rudimentär.
Welches Konzept hast du denn dafür, etwas Eigenes drüberstülpen ?

Rollo

[Jumpy]

Zitat von Rollo62:

Ich frage mich bei dem ganzen ORM nur immer ob es der richtige Weg ist.
Datenbanken wurde noch gemacht um 1 bis 1Mio. Datensätze zu verwalten.
ORM mit Listen im Speicher (OK, ich lass man das intelligente Speicherverwalten weg),
das läuft doch bei 1 Mio. Datensätze in eine Krise.

Ob du nun die 1 Mio. Datensätze in Listen mit Objekten oder aber in einem Dataset hast, wenn du dir 1 Mio. Datensätze von der DB holst, hast du die halt im Speicher. Aufpassen was du dir an Datensätzen holst must du immer selber, egal ob mit oder ohne ORM.

[haentschman]

Hallöle...

Zitat:

Ich frage mich bei dem ganzen ORM nur immer ob es der richtige Weg ist.

...für mich gibt es keinen Anderen. Ich bin durch die Einschränkungen der datensensitiven Controls, der Datasets, und vor Allem dem Durcheinander mit den Querys auf den Forms dazu gekommen. Im früherem Leben habe ich auch die Queries auf der Form mit DB Controls gehabt. Mit steigenden Anforderungen war das mir einfach zu unübersichtlich. Deshalb habe ich nach einer anderen Möglichkeit gesucht und gefunden...

Zitat:

ORM mit Listen im Speicher (OK, ich lass man das intelligente Speicherverwalten weg), das läuft doch bei 1 Mio. Datensätze in eine Krise.

...wie schon Jumpy sagte:

Zitat:

Ob du nun die 1 Mio. Datensätze in Listen mit Objekten oder aber in einem Dataset hast, wenn du dir 1 Mio. Datensätze von der DB holst, hast du die halt im Speicher. Aufpassen was du dir an Datensätzen holst must du immer selber, egal ob mit oder ohne ORM.

...du mußt selbst entscheiden welche Datensätze zu holst. Der Rest liegt im Datengrab...

Zitat:

Dann die Anbindung der Daten an die Controls.

...wo ist das Problem? Manches muß man auch manuell machen. Dafür heißt es auch programmieren...

Zitat:

Im Prinzip bin ich ja voll dafür, also heist die Richtung LiveBinding, nur leider funktioniert das nur rudimentär.

Livebindings habe ich probiert. Overhead war mir deutlich zu groß. Dann lieber klassisch. http://www.delphipraxis.net/190711-l...ceadapter.html

Zitat:

Welches Konzept hast du denn dafür, etwas Eigenes drüberstülpen ?

...weniger Probleme.

[Rollo62]

Ich binn dann wohl immer noch im Irrglauben das die Datasets nicht Alle Daten im Speicher halten, sondern nur intelligent per Chinks sich die passenden Häppchen holen.

Das hängt sicher vom Query ab, ein FDMemTable oder ClientDataSet hat Alles im Speicher,
aber was ist mit TFDQuery, oder ähnlichen Konstrukten ?

Die sollen das doch genau das Daten- und MemoryManagement vor mir Kapseln.

ORM ist gut und richtig, das sehe ich auch so.
Aber warum eigentlich nicht direkt von TDataset auf die Controls binden ?
Warum unbedings Objekte dazwischenbauen ?
(Ok, ich verstehe das man in den Objekten tolle Logik reinbauen kann, aber sollte man das wirklich dort machen) ?

Mit einer Wrapperklasse sollte das doch "einfach" möglichs ein.
TDbGrid macht das doch im Prinzip auch so, nur der der Wrapper im DBGrid selber ist, sozusagen.

LiveBinding per Code macht das im Prinzip so, mit FillExpressions z.B. für ListView,
und da glaube ich eben auch das dies der richtige Weg ist, das per RTTI zu entkoppeln.

So in dieser Richtung, am liebsten per Code:

Delphi-Quellcode:

   FDb.Bind(Query1, ListView, 'Name',  'Text')
      .Bind(Query1, ListView, 'Descr', 'Detail')
      .Bind(Query1, ListView, 'ImgId', 'ImageIndex')
      .Bind(Query1, Grid1,    '*')
      .Bind(Query1, Edit1,    'Name',  'Text',  dbBidirectional)
      ...
      ;

Rollo

[Uwe Raabe]

Zitat von Rollo62:

Ich binn dann wohl immer noch im Irrglauben das die Datasets nicht Alle Daten im Speicher halten, sondern nur intelligent per Chinks sich die passenden Häppchen holen.

Das hängt sicher vom Query ab, ein FDMemTable oder ClientDataSet hat Alles im Speicher,
aber was ist mit TFDQuery, oder ähnlichen Konstrukten ?

TFDQuery holt sich zwar die Daten häppchenweise, behält diese aber im Speicher - außer, es ist Unidirectional aktiv, dann werden die bereits besuchten Datensätze wieder aus dem Speicher geworfen.

Bezüglich ORM und DataSet/DBControls: Bei TMS Aurelius gibt es extra ein TAureliusDataset um die beiden Welten wieder zu vereinen.

[haentschman]

Zitat:

Aber warum eigentlich nicht direkt von TDataset auf die Controls binden ?

1. u.a. Faulheit. Ich habe die Faxen von ständig Query.FieldByName('FBlubb').AsInteger voll.
2. Weil ich die Daten im DataSet nicht strukturieren kann. Ähnlich einer Ordnerstruktur.

Zitat:

Warum unbedings Objekte dazwischenbauen ?

1. Im Quelltext steht kein einziger Feldname.
2. Die Datenbank oder die Datenquelle ist komplett getrennt. Die Daten können über das Interface aus Oma´s Küchenschrank kommen. Der Küchenschrank kennt kein DataSet sondern XML...
3. Das macht das Wechseln zwischen den Datenbanken / Quellen einfacher. Getrennte Statements je Interface für die verschieden DBMS.
4. Am Breakpoint kann man sich das komplette Objekt mit seinen Daten ansehen.

eine Bitte:

Zitat:

Bei TMS Aurelius gibt es

...das wir in diesem Tutorial nur über dieses Beispiel ORM diskutieren. Danke.

[Rollo62]

Wenn ich das richtig sehe hast du keine Interaktion drin, die Controls werden gefüllt.
Der Spass fängt aber dann an wenn du ein Grid oder Listview scrollen und editieren möchtest,
wenn Master-Detail sich synchronisieren müssen, korrekt die Daten in die DB zurückschreiben, etc..
Das müsste ja meiner Meinung nach auch gekapselt werden, das will man nicht immer wieder neu schreiben müssen.
Ich sehe das so das es eine Art "Bindings" in irgendeiner Form geben müsste, zum einen für die Daten (so wie du es hast z.B.), zum anderen eben diese Events (abhängig vom jeweiligen Control
und "Style" der Bedienung).

Wie würdest du denn so etwas bei deinem Vorschlag lösen ?

Rollo

[Fritzew]

Danke für das Tutorial.
Da es nicht nur ORM sondern auch Interfaces behandelt, oder besser gesagt auch zeigt wie die Benutzung aussehen kann, finde ich es wirklich gut.
Klar gibt es da viele verschiedene Ansätze, aber um aufzuzeigen wie man etwas auch anders machen kann finde ich es toll.
Was mit immer wieder auffällt in unserer "Delphi" Welt, ist das neue Ansätze es hier wirklich schwer haben.

[p80286]

Erst einmal vielen Dank!

Für den Datenbank-Teil hätte ich noch die eine oder andere Idee, aber das wären nur Detailänderungen, die mir pers. besser in den Kram passen würden. Den Interface-Teil habe ich zwar verstanden, glaube ich, aber der Vorteil erschließt sich mir nicht so recht. Mit einem TDataModule kommt man (ich) genauso weit, einziges Problem(?) für jede DB brauch ich ein eigenes Modul aber ein MyDM.GetPersonList(pl:tPersonlist) sollte immer die (formal) gleiche Liste liefern.

Gruß
K-H