Benutzer aus TObjectlist speichern

[scrat1979]

Liebe Community,

Ich möchte den Titel mal etwas Sinn verleihen. Ich habe - hier als Beispiel - einige Objecte in einer TObjectlist. Als Beispiel habe ich eine TObjectList (TUserList), welche die verschiedenen Benutzerobjekte (TUserInfo) verwaltet. Dies ist die Ausgangssituation. Nun möchte ich die verschiedenen Objekte in einer Datenbank speichern. Das speichern, laden, editieren etc. ist überhaupt kein Problem. Meine Frage ist eher, wo ich diese Logik nun implementiere. In der ObjectList oder in den einzelnen Objekten - Quasi die best practise.

Meine aktuelle Überlegung:

1.) Eine CustomUserlist, welche die einzelnen Methoden zum Speichern, Löschen etc. abstrakt definiert
2.) Die abgeleiteten Klassen implementieren die Funktionen, so dass ich hier als Ziel eine Datenbank oder ein eigenes Dateiformat nehmen könnte. Desweiteren kann man durch ableiten einer neuen Klasse die Funktionalität schnell um neue Formate erweitern
3.) die einzelnen Objekte kennen ihren Zusand (Neu, Löschen, Editieren, Unchanged)
4.) die Logik wird in der (abgeleiteten) TObjektlist implementiert und geht die einzelnen Objekte durch...

Alternativ könnte ich auch eine eigene Klasse zum Speichern erstellen (quasi als „Adapter“), welche die Logik implementiert (wie würde das gehen?). Ein Problem sehe ich hier, dass sowohl die ObjektList die Klasse kenne muss, die „Logik-Klasse“ aber auch die ObjectList, was ja zirkuläre Referenzen bedeuten würde.

Meine Frage: was haltet ihr von meinem Vorgehen und wie löst ihr das bei euch?

Danke im Voraus für eure Ideen!

P.S.: Etwaige Rechtschreibfehler bitte ich zu entschuldigen, die Rechtschreibkorrektur des Handys treibt mich in den Wahnsinn

[haentschman]

Moin...

Zitat:

Meine Frage ist eher, wo ich diese Logik nun implementiere. In der ObjectList oder in den einzelnen Objekten - Quasi die best practise.

Imho im Objekt ganz falsch... Das Objekt hat die Datenbank nicht zu kennen!

Ich setze noch einen drauf. Die Datenbanklogik steckt in einem Interface. Die Anwendung kennt nur das Interface. Das hat den Vorteil, daß man Mal eben die Datenbank austauschen kann.

Delphi-Quellcode:

IdVA_Database = interface(IdDatabaseUser)
  ['{C1BC6FE3-9586-4D92-8221-A3DD030E80B5}']
  procedure AddToLogServer(DeviceID: Integer; Time: TDateTime; Text: string; MessageState: TdMessageState);
  procedure AddToLogClient(UserID: Integer; Time: TDateTime; Text: string; MessageState: TdMessageState);
  property LogCount: Integer read GetLogCount write SetLogCount;
  function Save(aMasterDevice: TMasterDevice): Integer; overload;
  ...

TDatabaseIB = class(TInterfacedObject, IdVA_Database)

Speichern am Beispiel eines Objektes (TMasterDevice):

Delphi-Quellcode:

TdDataState = (ddsCreated, ddsNormal, ddsNew, ddsEdit, ddsModified, ddsDeleted, ddsNewModified, ddsLocked, ddsUnlocked, ddsUnknown);

function TDatabaseIB.CreateQuery: TUniQuery;
begin
  Result := TUniQuery.Create(nil);
  Result.Connection := FConnection;
end;

function TDatabaseIB.Save(aMasterDevice: TMasterDevice): Integer;
var
  Qry: TUniQuery;
begin
  Result := -1;
  Qry := CreateQuery;
  try
    case aMasterDevice.State of
      ddsNew:
        begin
          Qry.SQL.Text := GetSQLByName('SER_INSERT_MASTERDEVICE');
          Qry.ParamByName('DTI').AsInteger := Ord(aMasterDevice.DeviceType);
          Qry.ParamByName('FNA').AsString := aMasterDevice.Name;
          Qry.ParamByName('FCA').AsString := aMasterDevice.Caption;
          Qry.ParamByName('MOD').AsString := aMasterDevice.Version.Model;
          Qry.ParamByName('APP').AsString := aMasterDevice.Version.AppVersion;
          Qry.ParamByName('SYS').AsString := aMasterDevice.Version.SysVersion;
          Qry.ParamByName('FHO').AsString := aMasterDevice.Host;
          Qry.ParamByName('USN').AsString := aMasterDevice.UserName;
          Qry.ParamByName('PAW').AsString := aMasterDevice.PasswordEncrypted;
          Qry.ParamByName('ACT').AsInteger := Integer(aMasterDevice.Active);
          Qry.ParamByName('ISV').AsInteger := Integer(aMasterDevice.IsValid);
          Qry.ParamByName('CON').AsString := aMasterDevice.ConfigurationName;
          Qry.ParamByName('LRD').AsInteger := aMasterDevice.LastReadDeviceID;
          Qry.ExecSQL;
          aMasterDevice.ID := Qry.ParamByName('RET_ID').AsInteger;
          Result := aMasterDevice.ID;
        end;
      ddsEdit:
        begin
          Qry.SQL.Text := GetSQLByName('SER_EDIT_MASTERDEVICE');
          Qry.ParamByName('ID').AsInteger := aMasterDevice.ID;
          Qry.ParamByName('DTI').AsInteger := Ord(aMasterDevice.DeviceType);
          Qry.ParamByName('FNA').AsString := aMasterDevice.Name;
          Qry.ParamByName('FCA').AsString := aMasterDevice.Caption;
          Qry.ParamByName('MOD').AsString := aMasterDevice.Version.Model;
          Qry.ParamByName('APP').AsString := aMasterDevice.Version.AppVersion;
          Qry.ParamByName('SYS').AsString := aMasterDevice.Version.SysVersion;
          Qry.ParamByName('FHO').AsString := aMasterDevice.Host;
          Qry.ParamByName('USN').AsString := aMasterDevice.UserName;
          Qry.ParamByName('PAW').AsString := aMasterDevice.PasswordEncrypted;
          Qry.ParamByName('ACT').AsInteger := Integer(aMasterDevice.Active);
          Qry.ParamByName('ISV').AsInteger := Integer(aMasterDevice.IsValid);
          Qry.ParamByName('CON').AsString := aMasterDevice.ConfigurationName;
          Qry.ParamByName('LRD').AsInteger := aMasterDevice.LastReadDeviceID;
          Qry.ExecSQL;
          aMasterDevice.State := ddsNormal;
          Result := aMasterDevice.ID;
        end;
      ddsDeleted:
        begin
          Qry.SQL.Text := GetSQLByName('SER_DELETE_MASTERDEVICE');
          Qry.ParamByName('ID').AsInteger := aMasterDevice.ID;
          Qry.ExecSQL;
          Result := aMasterDevice.ID;
        end;
    end;
  finally
    Qry.Free;
  end;
end;
...

FDatabase.Save(MasterDevice); // fertsch

GetSQLByName('SER_EDIT_MASTERDEVICE') gehört zu SQL Speichern in Ressourcen. http://www.delphipraxis.net/190316-d...e-creator.html siehe Handbuch.

Zum Gesamten gehört auch der Aufbau der Connection u.a. dazu. Wenn du deine SQL aber über das ganze Programm verteilt hast, wird es eher schwierig diese Konzept durchzusetzen.

[Der schöne Günther]

Für so etwas gibt es Automatismen:
https://de.wikipedia.org/wiki/Objekt...nale_Abbildung (ORM)

Für Delphi gibt es da auch einige, einfallen tun mir spontan
- mORMot
- Spring4D (siehe Interview mit Stevie auf Entwickler.de)

Ausprobiert habe ich selbst keins davon, wir machen das auch wie die letzten Hinterwäldler von Hand

[haentschman]

Zitat:

Für so etwas gibt es Automatismen

...ob der Aufwand gerechtfertigt ist (eine Objektliste), muß jeder selbst entscheiden. Persönlich denke ich, können die Frameworks einfach zu viel was ich nicht brauche...

Zitat:

wir machen das auch wie die letzten Hinterwäldler von Hand

Da weißt du dann aber auch wo die Probleme liegen wenn mal etwas schief läuft.

[scrat1979]

Vielen Dank für die Antworten und sorry für die späte Rückmeldung. Ich war die letzten Tage nicht besonders fit und die Family glich einem Lazerett Aber wieder alles gut.

Die Idee mit den Interfaces klingt gut. Ich habe schon einige Tutorials durchgelesen aber so richtig bin ich noch nicht durchgestiegen. Werde mich noch einmal damit beschäftigen. Bis dahin werde ich es mit einer eigenen Klasse wie in meinem ersten Post lösen. Die Logik implementiere ich dann in der ObjectList, die einzelnen Datensätze kennen ihren jeweiligen Zustand. Analog zum Vorschlag von haetschman.

Was mir auch sehr gut gefällt ist die Idee, die SQL-Anweisungen im Resourcen-Teil zu speichern um diese ggf. Ohne neu compilieren zu müssen anpassen zu können. Sehr nice

Zum Glück habe ich noch keine Logik implementiert und die (wenigen) Daten von Hand in die Datenbank eingegeben. Bisher werden die Datensätze über eine simple SELECT-Anweisung lediglich ausgelesenen. Die Verwaltung im Programm soll - neben dem Lerneffekt - die Verwaltung etwas komfortabler machen.

Nochmals besten Dank für das Feedback! schöne Restwoche euch allen. Man liest sich