Der Ort der Registrierung ist im Wesentlichen egal, sie sollte lediglich chronoligisch gesehen vor der Verwendung stattfinden...
Mir ist der Sinn hinter dem ClassArray nicht ganz klar. In Deinem Kommentar schreibst Du, dass hier zu jeder Tabelle (Entität) eine geeignete Klasse registriert sein sollte, und hinterlegst stattdessen eine textuelle Bezeichnung, die der der Entität zu entsprechend scheint ("Ansprachpartner", "Auftrag", etc.). Dies ist nach meinem Empfinden eine redundante Information, weil sie bereits in Deinem Datenbankschema existiert, oder nicht?
Was spricht also dagegen, die Schemainformationen zu nutzen und die Bezeichnung Deiner Entität als Key für Dein Mapping zu verwenden. In der Configuration könnte nun hinterlegt werden, wie ein Schlüssel, zB "Ansprechpartner" auf einen Klassennamen, hier zB "TPDAnsprechpartner" abbilden soll. Falls Du in Deiner Konfiguration (zB in einer externen Datei) keine explizite Angabe machst, könnte dieses Mapping jedoch durch einfaches Konkatenieren geschehen, also etwa in der Art
Delphi-Quellcode:
function TConfiguration.GetClassNameFromKey(const AKey: string): string;
begin
if KeyWasConfigured(AKey) then
Result := GetValueFromKey(AKey)
else
Result := Format('%s%s%s', [FPrefix, FKey, FPostfix]);
end;
Existieren nun drei verschiedene geeignete Implementierungen für die Entität "Ansprechpartner", kann zur Laufzeit entschieden werden, ob die Klasse "TPDAnsprechpartner" oder eine andere durch ihren Klassennamen konfigurierte Klasse verwendet werden sollte.
Interessant ist, dass Du mithilfe des Datenbankschemas eine Prüfung durchführen kannst, die sicherstellt, dass bei einer Null-Konfiguration (ohne angepasstes Mapping) alle benötigten Klassen existieren (registriert worden sind), bzw beim Laden einer Konfiguration mit Anpassungen entsprechend verfährt und unter Ausgabe eines Hinweises für ggf nicht vorhandene Klassen auf den Null-Wert verfällt.