Codedesign für modulare Anwendung

[Meflin]

Zitat:

Zitat von Blup (Beitrag 1230585)

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:

Zitat von Codehunter (Beitrag 1234010)

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.

[Furtbichler]

Ich wollte nur kurz etwas zur Eingangsfrage einwerfen:

Zitat:

Zitat von Codehunter (Beitrag 1230515)

Darum war mein Gedanke, ich verwende nur eine zentrale UniConnection-Komponente und lasse sämtliche Module einer Anwendungsinstanz darüber laufen. Dann würde das ConnectionTimeout-Management auch viel besser funktionieren.

Ich finde nicht, das das eine gute Idee ist, denn dadurch würden Zugriffe doch unnötigerweise serialisiert. Mir scheint, das UniDAC hier ein Connection-Pooling eingebaut hat, was sehr praktisch ist. Ich sehe nämlich überhaupt keinen Nachteil, 20-30 Verbindungen gleichzeitig offen zu halten: Den Server juckt das doch gar nicht. Durch das Pooling will man doch gerade das umständliche Weiterreichen einer TConnection vermeiden.

Das Pooling unterstützt ja direkt das Plugin-Konzept. Jedes Plugin holt sich eine eigene Connection und muss sich nicht darum scheren, ob da gerade eine Transaktion läuft, oder nicht.

Das entbindet dich aber nicht davon, Connection- oder Transaktionskomponenten weiterzureichen, gerade *wegen* der Transaktionsproblematik.

[Codehunter]

Soweit ich UniDAC verstanden habe, betreibt dieses ein Transaktionspooling und kein Verbindungspooling. Das Pooling findet in der TUniConnection statt und gerade deswegen hielt ich es für eine gute Idee, die Verbindung zwischen Hostanwendung und Plugin zu teilen.

Im Gegensatz zu Webservern a la Apache oder IIS scheinen Datenbankserver wie MySQL und MariaDB gar nicht so begeistert zu sein über viele konkurrierende Verbindungen. Per Default scheinen die auf weniger als 100 gleichzeitige Verbindungen eingestellt zu sein.