Interface- und Klassenstruktur für entkoppelte GUI und Anwendungslogik

[Ghostwalker]

Ich würde das ganze über ein weiteres Interface machen, das dir letztlich eine Liste mit Felder liefert (wird auch über die Geräte-DLL erzeugt).

Diese Liste liefert dir für jeden gerätespecifischen Paremter so sachen wie den Namen des Feldes, den Typ (Integer, String, Enum usw) sowie das Value. Damit kannst du die Gui dynamisch erzeugen.

Die gleiche Liste kannst du auch an eine Datenbank-DLL weiterreichen, die dir das ganze dann speichert.

Das ganze könnte ungefähr so aussehen:

Gemeinsame Typen (über alle DLL's und der APP)

Delphi-Quellcode:

Type
  TDataField = Record
             Name : string;
             Type : String;
             value: TValue;
  end;

  TFieldList = TList<TDataField>;

  TDataList = TList<TFieldList>;

Interfaces

Delphi-Quellcode:

  //Sammeln der Daten
  IDataCollector = Interface
  [GUID]
  function Collect:integer;
  function GetLastError:Integer;
  function GetData:TDataList;
  end;

  //Speichern der Daten IRGENDWO
  IDataSaver = Interface
  [GUID]
  function SetDataList(data:TDataList):boolean;
  Procedure Save;
  end;

  //Laden der Daten von IRGENDWO
  IDataLoader = Interface
  [GUID]
  Procedure Load;
  Function GetDataList:TDataList;

Damit kannst du das ganze handhaben, ohne das deine App die konkrete Struktur der Gerätedaten kennt. Und über die beiden anderen Interfaces kannst es sogar soweit treiben, das die App nocht nicht mal weiß, wo die Daten gespeichert werden, den ob das dann in einer Datenbank oder einer Datei oder in die Cloud ist, ist hier auch egal, solange das ganze die entsprechenden Interfaces liefert.