Codedesign für modulare Anwendung

[Codehunter]

Moin!

Im Zusammenhang mit meiner Frage im UniDAC-Forum möchte ich hier das Grundsätzliche thematisieren. Es handelt sich um die Planung zu einer gänzlich neuen Anwendung.

Die Anwendung soll mit UniDAC zur Datenbankverbindung arbeiten und modular aufgebaut sein. Sprich, es gibt einen Programmkern und dieser lädt einzelne Module (DLL) nach, welche dann das jeweilige GUI bilden. Mein Grundgedanke war, die eigentliche Datenbankverbindung im Hauptprogramm anzusiedeln und die einzelnen Table- bzw. Query-Komponenten in den Modulen. Die Anzahl und Kombination von Modulen richtet sich nach der Lizensierung.

Beim Initialisieren des Moduls wird die Connection-Instanz aus der Hauptanwendung einer DLL-globalen Variablen und darüber dann den dort angelegten Tables usw. zugewiesen. Für den Datenaustausch zwischen Hauptprogramm und Modulen habe ich an FastMM4 mit aktivierten SharedMem-Optionen gedacht.

In einem ersten Test funktioniert das Konzept: Die Connection verbindet sich mit der DB und die Table im Modul lädt Daten aus der DB in ein DBGrid. Doch schon beim Ändern von Daten knallts: "TUniEncryption kann nicht zu TUniEncryption zugewiesen werden".

Bevor ich mich jetzt aber im aufwendigen Debuggen festbeiße die Frage in die Runde hier: Ist das grundsätzliche Anwendungsdesign schon verkehrt? Theoretisch könnte auch jedes einzelne Modul seine eigene Connection aufbauen. Nur dann hat man je nachdem, wie viele Module der User gleichzeitig öffnet, viele gleichzeitige Datenbank-Sessions parallel aus einer einzigen Anwendung heraus. Gut, technisch ist das nicht so das Problem, aber ich halte das für kein gutes Konzept.

Was meint ihr?
Grüße, Cody

[mjustin]

Müssen alle Datenbankverbindungen denn ständig geöffnet sein? Bei InterBase und Firebird wird das nach Möglichkeit vermieden, da dann lang laufende Transaktionen den Server überlasten können.

Als Mittelweg käme ein Connection Pool in Frage. Bei anderen Umgebungen (Java, .Net) eine Standardlösung, ich kenne UniDaC aber nicht.

Und dass es knallt ist nicht ungewöhnlich. Über DLL Grenzen hinweg ist die Arbeit mit Interfaces sicherer. Oder mit elemntaren Datentypen der Windows API.

[Codehunter]

Zitat:

Zitat von mjustin (Beitrag 1230513)

Müssen alle Datenbankverbindungen denn ständig geöffnet sein?

Soweit ich weiß öffnet UniDAC die eigentliche Verbindung nur dann, wenn ein DataSet auf Active = TRUE gesetzt wird. Gewohnheitsmäßig öffne und schließe ich die Verbindung vor bzw. nach einer Datenbank-Transaktion. Das geht aber nur, solange man nicht mit DB-Aware-Komponenten arbeitet. Davon unabhängig kann man bei UniDAC verschiedene Server-Parameter angeben, darunter auch den Connection Timeout. Per Default ist der 15 Sekunden, danach wird die Verbindung abgebaut.

Trotzdem kann der User theoretisch die Anwendung dazu bringen, mit vielen gleichzeitig geöffneten Modulen 20 oder 30 offene Datenbank-Sessions zu erzeugen. 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.

[Bernhard Geyer]

Du hast das berühmte Problem wenn du kein gemeinsammen Laufzeitbibliotheken verwendest. Dort ist dan Exe.TObject != Dll.TObject.

Du könntest aber versuchen das mit Interfaces hin zu bekommen. Das sollte das o.g. Problem nicht haben wenn man keine gemeinsamen Laufzeitbibliotheken verwendet.

[mjustin]

Zitat:

Zitat von Codehunter (Beitrag 1230515)

Zitat:

Zitat von mjustin (Beitrag 1230513)

Müssen alle Datenbankverbindungen denn ständig geöffnet sein?

Soweit ich weiß öffnet UniDAC die eigentliche Verbindung nur dann, wenn ein DataSet auf Active = TRUE gesetzt wird. Gewohnheitsmäßig öffne und schließe ich die Verbindung vor bzw. nach einer Datenbank-Transaktion. Das geht aber nur, solange man nicht mit DB-Aware-Komponenten arbeitet.

Das gilt nicht, wenn man mit ClientDataSet arbeitet, denn ein an ein ClientDataSet gebundene Datenbankkomponenten zeigen auch nach dem Schliessen des Datasets weiter alle Daten an und erlauben auch Eingaben. Für das Speichern wird dann wieder eine Verbindung aufgebaut.

Damit kann die Anwendung praktisch 99% der Zeit Offline, ohne Connection (und benutzte Lizenz) arbeiten.

[Codehunter]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230516)

Du hast das berühmte Problem wenn du kein gemeinsammen Laufzeitbibliotheken verwendest.

Ich hasse berühmte Probleme! Die brauchen immer großartige Lösungen ;-) Wenn ich das richtig verstehe, bildet jedes Binary das ohne Laufzeitbibliotheken kompiliert wird, sozusagen seine eigene kleine Welt. Mit Shared Memory in so einer Konstruktion versucht man quasi einen Stein von einem Planeten zum anderen zu werfen.

Sollte die Lösung jetzt so simpel sein, dass ich beide Binaries einfach mit Laufzeitbibliotheken kompiliere und dem Ganzen dann einfach die BPLs mitliefere?

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1230564)

Sollte die Lösung jetzt so simpel sein, dass ich beide Binaries einfach mit Laufzeitbibliotheken kompiliere und dem Ganzen dann einfach die BPLs mitliefere?

Nein, du darfst dann keine .dll benutzen, sondern eine .bpl. Das Laden dauert etwas länger als bei DLLs, aber ansonsten sollte es keine negativen Auswirkungen haben, sofern du die .bpl Versionen sauber verwaltest.

Schön ist das aber eher nicht. Besser wäre eine saubere DLL-Schnittstelle, es sei denn du brauchst die Datasets als echte TDatasets.

Wir haben dafür z.B. ein Interface auf das Hostprogramm, das automatisch (per allgemeiner Unit in der DLL, die entsprechende Funktionen exportiert) zur Verfügung steht und über das man Datasets anfordern kann. Die bekommt man dann als Interface und kann sie so ansteuern. Die Architektur ist so ähnlich wie du es beschreibst. ;-)

[Bernhard Geyer]

Zitat:

Zitat von Codehunter (Beitrag 1230564)

Mit Shared Memory in so einer Konstruktion versucht man quasi einen Stein von einem Planeten zum anderen zu werfen

Shred Memory hat schon seine Berechtigung. Es kann halt nur "dumme" Daten wie einfache Speicheranforderungen oder Strings über die DLL-Grenzen sauber transportieren.

[Codehunter]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230576)

Shred Memory hat schon seine Berechtigung.

*lol* Genau das passiert mir bei dem Projekt derzeit öfters (im wörtlichen Sinne)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1230576)

Es kann halt nur "dumme" Daten wie einfache Speicheranforderungen oder Strings über die DLL-Grenzen sauber transportieren.

Ja und genau beim Sharen komplexerer Daten/Objekte hab ich grad echte Verständnisprobleme.

[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:

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.