Ich möchte nochmals darauf hinweisen, dass gerade hier bei der Einhaltung von SoC dieses Problem nicht wirklich existiert, bzw. an nur einer überschaubaren Stelle auftritt.
Die Entity-Klassen für Aurelius (oder jedes andere ORM-Framework) spiegeln 1:1 die
SQL-Tabellen wieder und nur in den eher zufällig seltenen Fällen auch Anwendungs-Klassen.
Beispiel:
Delphi-Quellcode:
// Domain-Model
TAddress = record
Street: string;
PostalCode: string;
City: string;
end;
TContact = record
Id : Integer;
Firstname: string;
Lastname: string;
Addresses: TArray<TAddress>;
end;
und nun die ORM-Klassen, damit das auch in eine Datenbank rein kann
Delphi-Quellcode:
// Entity-Model
TContact = class
property Id: Integer;
// Concurrency-Conflicts-Detection
property Version: Integer;
property Firstname: string;
property Lastname: string;
end;
TContactAddress = class
property ContactId: Integer;
property Position: Integer;
property Street: string;
property PostalCode: string;
property City: string;
end;
Obwohl sich in beiden Informationen zu einem Kontakt befinden gibt es dennoch unterschiedliche Ansprüche an das Layout. Um das Addresses-Array auch exakt wiederherstellen zu können benötigt man zusätzlich auch die Position. Oder zum Erkennen von Concurrency-Conflicts die Version. Damit will man sich aber auf der Anwendungsebene nicht herumschlagen, zumal dieses (Position) auch wiederum der relationalen Datenbank geschuldet ist. Bei einer NoSQL-Datenbank könnte man darauf (Position) wiederum verzichten, denn dort wird auch die Reihenfolge der Adressen gespeichert.
Zitat
Baum-Darstellung
