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.