@Delbor
Das, was Du beschreibst, klingt schon ganz gut, aber Dein Quelltext lässt das nicht ganz erkennen.
Du könntest es Dir deutlich einfacher machen, aber müsstest dafür sicher Dein Projekt neu aufbauen.
Mal zwei Ansätze.
Empfehlenswert wäre m.E. folgender neuer Ansatz (mal am Beispiel Personen und Autos):
Du baust 2 Klassen:
Delphi-Quellcode:
TPerson = class
Vornme: string;
Nachname: string;
Autos: TList<TAuto>;
Kilometer: Integer;
end;
TAuto = class
Typ: string;
Farbe: string;
Fahrer: List<TPerson>;
Kilometer: Integer;
procedure Fahren(aFahrer: TPerson; aKM: Integer);
end;
Jetzt kannst Du Objekte erzeugen, im Speicher verwalten, in Listen zuordnen und Kilometer für Fahrer und Autos zählen.
Das sind die Businessklassen. Nur das brauchst Du, um die Kilometer für die Fahrer und Autos zu ermitteln.
Jetzt kannst Du schon mal testweise per Code einige Testpersonen und Autos anlegen und einige Strecken fahren.
Also zumindest kannst Du schon mal ein paar Testobjekte erzeugen.
Nun baust Du die
GUI, und Du kannst sehen, ob die Testdaten korrekt angezeigt werden und ob Du über die
GUI neue erzeugen kannst.
Bis hierher spielt die Datenbank noch keine Rolle!
Aber jetzt wollen wir die Daten natürlich doch irgendwie speichern.
Also müssen die Objekte irgendwie die Fähigkeit haben, gespeichert und gelesen zu werden.
Wenn es dafür eine einheitliche Regelung gibt ist das sicher sinnvoll.
Daher könnte man eine Basisklasse einführen, die das unterstützt:
Delphi-Quellcode:
TSaveLoad = class
procedure Save; virtual;
procedure Load; virtual;
end;
TPerson = class(TSaveLoad)
Vornme: string;
Nachname: string;
Autos: TList<TAuto>;
Kilometer: Integer;
procedure Save; override;
procedure Load; override;
end;
TAuto = class(TSaveLoad)
Typ: string;
Farbe: string;
Fahrer: List<TPerson>;
Kilometer: Integer;
procedure Fahren(aFahrer: TPerson; aKM: Integer);
procedure Save; override;
procedure Load; override;
end;
Wenn man die Daten einfach mal in einer Ini speichern will, kann man das in den überschriebenen Methoden Save und Load realisieren.
Wenn man dann auf eine Datenbank welchselt und später nochmal auf eine andere, ändert man einfach die Methoden wieder ab.
Eine andere Variante wäre, die Basisklasse und die Methoden Save und Load weg zu lassen und statt dessen einen DBManager zu bauen:
Also man erzeugt eine weitere Klasse
Delphi-Quellcode:
TDBManager = class
function GetAllPersons_WithoutCars: TList<TPerson>;
function LoadPerson(aPersonId: Integer): TPerson;
procedure SavePerson(aPerson: TPerson);
end;
Dann weiß nur der DBManager, wie die Verbindung zu den Datenbanktabellen herzustellen ist.
Man kann dann unterschiedliche BDManager für unterschiedliche Datenbanken erstellen und die jederzeit austauschen.
In ALLEN FÄLLEN sollte aber TPerson.Vorname IMMER TPerson.Vorname heißen, selbst wenn der ersten Datenbank die Personentabelle People und das Feld FirstName und in der neuen Datenbank die Tabelle Leute und das Feld Name_1 heisst.
NUR in den Methoden Save und Load bzw. in der anderen Variante in dem DBManager müssen die Anpassungen an die Datenbankänderungen vorgenommen werden.
Um wieder auf Dein Beispiel zurück zu kommen:
Statt z.B. in der Buinessklasse mit
FTblBild_IdBild: integer;
bzw.
FBildTabelleIdBild: integer;
zu arbeiten, wäre dort
fBildID: integer;
sinnvoll, weil die bei der Businesslogik eben interessiert.
Wie die passenden Daten aus einer Ini-Datei, aus Datenbank A, Datenbank B oder von Google geholt werden, ist für die Buinessklasse selbst und für die Benennung der Properties völlig uninteressant.
Genau das ist ja auch ein Ziel der
OOP, das man verhalten kapselt und auch überschreiben kann.
Sorry, falls das etwas chaotisch ist. Aber vielleicht hilft das ja dennoch mal auf einen besser strukturierten Ansatz.