Codedesign für modulare Anwendung

[Blup]

Jede DLL schleppt praktisch ihre eigene Implementation der UniDac-Komponenten mit.
Die kann identisch sein, muss aber nicht.
Selbst wenn diese identisch ist, kann der Kompiler dass nicht erkennen (es wird nur der Zeiger auf die Klasse verglichen und die sind immer unterschiedlich, auch wenn die Klassen den selben Namen tragen).

Ein Ausweg wäre alles mit BPL-Dateien umzusetzen, das betrifft dann auch die VCL und alle anderen Komponenten die gemeinsam genutzt werden.
Allerdings sind durch die Abhängigkeiten BPL-Dateien nicht so einfach austauschbar.
Wird eine BPL-Datei ausgetauscht, müssen auch alle davon abhängigen BPL-Dateien mit dieser Version neu kompiliert und ausgetauscht werden.

Eine andere Möglichkeit wäre eine ganz andere Plattform zu wählen, z.B. NET.

[Meflin]

Zitat von Blup:

Eine andere Möglichkeit wäre eine ganz andere Plattform zu wählen, z.B. NET.

Das war auch mein erster Gedanke... da bekommt man das mit dem Managed Extensibility Framework geschenkt (und ordentlich). Allerdings schätze ich mal, dass das für den TE keine Option sein wird...

[Codehunter]

Nö, nicht wirklich Wobei ich noch ergänzen möchte dass das Plugin-System nicht so gedacht ist dass Drittanbieter Plugins liefern können. Vielmehr will ich nur erreichen, dass ich in einer einheitlichen Host-Anwendung verschiedene GUI auf die selbe Datenbank setzen kann. Die Plugins kämen alle von mir.

[jaenicke]

Ich habe da einmal etwas zusammengebaut... siehe Anhang.

Wenn ich mal Zeit dafür haben sollte, schreibe ich dazu auch noch mehr.

[Codehunter]

Hallo!

Sorry dass ich mich jetzt erst wieder melde. Ich brüte da nun schon eine ganze Weile über deiner Demo. Was sich mir da noch nicht so recht erschließt: Du arbeitest da jetzt zwar mit Generics (was mal wieder Neuland für mich ist), aber prinzipiell schiebst du da über ein Interface auch nur einen UnicodeWide-String (AExample.Connection.Host) zwischen der DLL und der Hostanwendung hin und her. So weit war ich ja mit meinem Code auch, wenn auch wesentlich weniger elegant. Da sehe ich aber noch nix von wegen gemeinsamer Nutzung einer TConnection (bzw. im Fall von UniDAC einer TUniConnection).

Über das Thema Runtime-Packages habe ich viel nachgedacht, es aber am Ende wieder verworfen. Denn dadurch würde ich den Vorteil einer modularen Anwendung eigentlich wieder verspielen. Denn in der Praxis müsste ich zu jedem Modul-Installer sowohl die jeweils passend kompilierte Hostanwendung als auch sämtliche BPL-Packages mitliefern.

Vielleicht habe ich aber auch deine Demo nur nicht richtig verstanden. Kann ja sein, bin auch nur ein Newbie in Sachen Interfaces und Generics.

Grüße
Cody

[jaenicke]

Zitat von Codehunter:

Du arbeitest da jetzt zwar mit Generics (was mal wieder Neuland für mich ist), aber prinzipiell schiebst du da über ein Interface auch nur einen UnicodeWide-String (AExample.Connection.Host) zwischen der DLL und der Hostanwendung hin und her. So weit war ich ja mit meinem Code auch, wenn auch wesentlich weniger elegant. Da sehe ich aber noch nix von wegen gemeinsamer Nutzung einer TConnection (bzw. im Fall von UniDAC einer TUniConnection).

Das Interface kapselt ja die TConnection. Das müsstest du dann auch machen. Bei der Zuweisung an ein anderes Interface wird die in dem Objekt, das hinter dem Interface steckt wieder auf das Objekt gecastet. So kannst du dann deine Connection in ein Interface stecken, an die DLL übergeben und dort an ein anderes Interface zuweisen, das du ebenfalls von deiner Anwendung bekommen hast. Dieses löst dann das Objekt auf und weist es an die echte Connection Eigenschaft zu.