Object Daten-Layer

[Lemmy]

hi,

was mir ganz spontan einfällt: Mach ein Stringlist in der Du KEy=Value die Änderungen protokollierst, d.h. im Setter des property musst Du die Property und den neuen Wert in die Stringlist speichern. Beim Save gehst Du dann die Stringlist durch und speicherst die entsprechende Werte in der DB.

Wenn Du alle Änderungen in der SL speicherst könntest Du darüber auch eine Undo-Funktion bauen.


Füllen des Objekets: Klar über RTTI. den Präfix würde ich persönlich weglassen (was soll das F?) oder die ungarische Notation verwenden.
Problem dabei ist aber, dass in Datenbanken die Länge der Feldnamen beschränkt sein könnte (z.B. in Firebird) - in diesem Fall also kurze Feldnamen verwenden oder über eine Zuordnungsliste gehen (FeldnameDB=PropertyName) oder über die Attribute (wenn die neue RTTI verwendet wird).

Grüße

[Sir Rufo]

wie wäre es damit
Beim Lesen aus der DB müssen natürlich beide arrays (FOldData, FNewData) mit den Werten aus der DB befüllt werden.
Beim Speichern kann man nun diese Daten vergleichen.

Hieraus lässt sich auch schön eine Basisklasse bilden und die abgeleitete hat eigentlich nur noch die properties und benutzt die Getter/Setter der Basisklasse

Delphi-Quellcode:

type
  TKunde = class
  private
    FOldData = array of variant;
    FNewData = array of variant;
    procedure InternalSetter( index : integer; Value : Variant );
    function InternalGetter( index : integer ) : Variant;
  protected
    procedure SetIntData( index : integer; const Value : integer );
    function GetIntData( index : integer ) : integer;
    procedure SetStrData( index : integer; const Value : string );
    function GetStrData( index : integer ) : string;
  public
  published
    property id : integer index 0 read GetIntData write SetIntData;
    property plz : string index 1 read GetStrData write SetStrData;
    property ort : string index 2 read GetStrData write SetStrData;
  end;

procedure TKunde.InternalSetter( index : integer; Value : Variant );
begin
  FNewData[ index ] := Value;
end;

function InternalGetter( index : integer ) : Variant;
begin
  Result := FNewData[ index ];
end;

procedure TKunde.SetIntData( index : integer; const Value : integer );
begin
  InternalSetter( index, Value );
end;

function TKunde.GetIntData( index : integer ) : integer;
begin
  Result := VarToInt( InternalGetter( index ) );
end;

[DeddyH]

Wenn id den PK darstellt, dann würde ich die Property ReadOnly deklarieren, da der Wert ja vermutlich über einen Trigger und Generator befüllt wird statt durch Zuweisung.

[Sir Rufo]

Wieso, hängt von der Anwendung ab und Update dann so

Code:

UPDATE MeineTabelle SET id = :NewID WHERE id = :OldID

[DeddyH]

Ich gehe davon aus, dass ID ein künstlicher Schlüssel (PK) ist, der vom DBMS generiert wird. Den würde ich in den meisten Fällen nicht überschreiben wollen, mir fällt auch kein guter Grund für ein solches Überschreiben ein. Deshalb mein Vorschlag einer ReadOnly-Property, es sei denn, es ist ganz anders gemeint bzw. gewollt.

[Sir Rufo]

Zitat von DeddyH:

Ich gehe davon aus, dass ID ein künstlicher Schlüssel (PK) ist, der vom DBMS generiert wird. Den würde ich in den meisten Fällen nicht überschreiben wollen, mir fällt auch kein guter Grund für ein solches Überschreiben ein. Deshalb mein Vorschlag einer ReadOnly-Property, es sei denn, es ist ganz anders gemeint bzw. gewollt.

Es kommt halt drauf an, wer die Datenhoheit hat
Und in seinem Beispiel war id nicht ReadOnly