DLLs in komplexen Programm

[Sir Rufo]

Es ist doch völlig Wurst, auf welche DB die DLLs zugreifen (ok, da wo die zugreifen sollen, muss die Struktur da sein).

Aber grundsätzlich stellt mir die DLL einen Funktionstopf zur Verfügung und eine starre Anbindung an die Datenbank X ist ja nicht so schön.

Die Hauptanwendung weiß, wo die DB (Server, Zugangsdaten, Schema) zu finden ist.
In der HA gibt es einen Plugin-Verwalter (eigene Unit), der die vorhandenen Plugins (die DLLs) lädt und initialisiert (Zugangsdaten zur DB). Jetzt kann die HA auf die Funktionen der Plugins zugreifen.

Die Kommunikation unter den Plugins sollte aber über den Plugin-Verwalter gehen (z.B. via CallBack)
denn die Hauptaufgabe bei dem besteht darin, alle vorhandenen Plugins zu kennen und zu verwalten.
Der kann dann auch Plugin A mitteilen, dass es Plugin B gibt und per CallBack zu erreichen ist.

Dadurch erspart man sich die umständliche Verknüpfung der einzelnen Plugins (hier ja DLLs) untereinander, denn das Wesen von Plugins ist ja, dass diese optional und somit nicht vorhanden sein müssen.

Ach ja, wenn es nur eine DB gibt, dann bräuchten die DLLs eigentlich auch keine Informationen zur DB, denn der Zugriff auf selbige könnte ja auch über den Plugin-Manager laufen (siehe Skizze von s.h.a.r.k.)

Wie man schon sieht ist es gerade bei einem solchen Plugin-System exorbitant wichtig viel Zeit in die Planung zu stecken.
Welches Plugin soll welche Funktionen ausführen und welche Informationen werden dafür benötigt.
Wenn das fertig ist, dann kann man entscheiden auf welchem Weg man diese Informationen bekommt (holt das Plugin die Informationen direkt, über einen Callback oder werden diese schon beim Aufruf mitgeliefert)

[Blup]

Im Prinzip geht es doch darum, das alle Teile möglichst unabhängig von einander funktionieren.
Darum würde ich Interface einsetzen.

Zitat:

Dazu, was die DLLs können müssen:
- muss Mehoden exportieren --> ok
- muss Forms exportieren --> ok

Statt dessen sollte ein Interface beim Anwendungskern in einer Interface-Liste registriert werden. Wo immer ein bestimmtes Interface benötigt wird, wird es vom Kern geholt.

Zitat:

- muss auf (versch.) Datenbanken zugreifen können --> PROBLEM!

Verschiedene Datenbanksysteme oder verschiedene Datenbankdateien?
Eigentlich braucht man ja nur die Verbindungsparameter z.B. als Connectstring weiter zu geben.

Zitat:

-> müsste dynamisch Komponenten erstellen können ???

Sollen sie, warum auch nicht?

Zitat:

- muss Einträge im Main Menu vornehmen --> kann ich noch nicht, sollte wohl aber nicht so schwierig sein
- muss eine neue Seite im Page Control anlegen und eigen Form darin anzeigen --> kann ich auch noch nicht, lässt sich aber auch aneignen, denk ich

Das ist Aufgabe der GUI. Die GUI fragt alle beim Anwendungskern registrierten Interface ab und prüft für jedes, ob ein Interface suportet wird, das Informationen zu zusätzlichen Menüpunkten bereitstellt. Diese werden angelegt und mit der Funktion aus dem Interface verknüpft.
Die GUI könnte sich beim Anwendungskern auch als Observer für die registrierten Interface anmelden, um gegebenenfalls auf Änderung reagieren zu können.

Code:

+----------------+    +--------------+--------------+
|                | -- | Interface     | GUI           |
|                |    +--------------+--------------+
|                |    
|                |    +--------------+--------------+
|                | -- | Interface     | Planung1-DLL |
|                |    +--------------+--------------+
| Anwendungskern |    
|                |    +--------------+--------------+
|                | -- | Interface     | Planung2-DLL |
|                |    +--------------+--------------+
|                |    
|                |    +--------------+--------------+
|                | -- | Interface     | Planung3-DLL |
+----------------+    +--------------+--------------+

Man könnte sogar so weit gehn, jeweils eine DLL für die fachliche Logik und eine für die Oberfläche zu dieser Logik einzusetzen.
Dann wäre die Oberfläche komplett austauschbar (z.B. Web-Darstellung), ohne die eigentliche Anwendung zu beeinflussen.

[hans ditter]

Wow, gute Antworten... aber damit bin ich grade überfordert...

Also, ich hab die Hauptanwendung (HA), die hat eine (?) Komponente für den Datenbankzugriff. Dann hab ich eine Unit, die die gesamte (?) Kommunikation zwischen HA und den DLLs regelt. Dann hab ich noch die DLL, die Informationen (wie z.B. den ConnectionString) preisgibt, und damit den Zugriff auf die Datenbankdatei ermöglicht.

@Sir Rufo:
Aber wie mache ich das mit der Unit? Wie ich damit das Laden und initialisieren der DLL hinbekomme ist mir noch klar. Aber wie mache ich das mit den ganzen exportierten Methoden der DLL? Soll ich die auch nur über die Unit aufrufen? Und wie macht man das dann?
Was bedeutet ein Callback? Callback = zurückrufen? Aber wie hängt das mit der Kommunikation zwischen versch. DLLs zusammen?

Zum Aufbau nochmal: Also, bis jetzt haben alle (es sind bisher nur 2) Module eine eigene Datenbankdatei. Daher müssen die versch. DLLs wohl doch Verbindungsdaten exportieren...

@Blup:
Was genau meinst du mit Anwendungskern? Ich kann mir darunter nicht so richtig was vorstellen...
Und wie in Himmels Namen funktioniert das mit den Interface? Ich hab schon ganz häufig (praktisch immer wenn's um DLLs ging) von diesem Interface gehört, kann mir aber immer noch nicht vorstellen/erklären, wie das funktionieren soll. Kannst du dafür möglicherweise ein Tutorial empfehlen? Und vor allem: Was wäre der Vorteil an einem Interface gegenüber einem Programm ohne Interface?

Eine eher allgemeine Frage hab ich auch noch. Ich schreibe mir jetzt 2 Module: Modul1 und Modul2 und eine HA. Jetzt möchte ich aber in einem halben Jahr, ich habe bis dahin die beiden vorhandenen Module fleißig benutzt, ein weiteres hinzufügen. Was muss ich dann machen? Geht das überhaupt? Wenn ja, kommen da irgendwelche großen Probleme auf mich zu?

Mein Gott, schon wieder so viele Fragen... Ich freue mich auf eure Antworten!

schneeige Grüße, hans ditter