DLLs in komplexen Programm

[s.h.a.r.k]

Das war Sir Rufo hier meint ist, dass es mindestens drei Schichten geben soll. Zum einen mal die GUI, das ist klar. Mit irgendwas muss der User ja kommunizieren. Daneben dann eine Schicht, die die ganze Verwaltung der DLLs übernimmt und auch entsprechende Schnittstellen für die GUI und für die DLLs anbietet. Und darunter dann die Schicht mit den DLLs. Hier mal ein kleines Bild:

Code:

    +-------+
    |  GUI   |
    +-------+
        ^
        |
        v
    +--------------+         +-------------------------+         +------+
    |  MANAGEMENT   | <-----> |  Datenbank-Schnistelle   | <-----> |  DB   |
    +--------------+         +-------------------------+         +------+
        ^
        |
        v
    +--------+
    |  DLLs   |
    +--------+

@Sir Rufo: Bitte nicht hauen, wenn ich hier was falsch verstanden habe

[hans ditter]

okeeeee......
Ich sollte also eine eigene Unit für alle organisatorischen Sachen erstellen?
Das würde also bedeuten, dass ich die GUI hab, die dem Nutzer das Kommunizieren mit meinem Programm erlaubt, dann hab ich die versch. DLLs, die Forms und Methoden exportieren, und eine Unit, die beides miteinander vereint. Hab ich das recht verstanden?

Das würde dann also bedeuten, dass die versch. DLLs (die ja z.B. eine eigene Datasource Komponente brauchen) "ihre" Komponenten zur Laufzeit dynamisch in der "Managementunit" erstellen. Aber wie geht das? Bei einer Unit kann man doch nicht während das Programm ausgeführt wird dynamisch weitere Komponeneten erstellen, oder?

Und bei einer Sache hab ich noch Schwierigkeiten:

Zitat von s.h.a.r.k:

[...] und auch entsprechende Schnittstellen für die GUI und für die DLLs anbietet.

Was genau meinst du hier mit Schnittstellen?

lg, hans ditter

[hans ditter]

Also, ich hab mir nochmal genauer Gedanken gemacht und versucht, die elementaren Fragen und Aufgaben herauszuarbeiten.

Das ganze soll so aussehen:

Code:

      +-------------------------------------------------+
      |             GUI (Programmoberfläche)             |
      +-------------------------------------------------+
                    /          |             \
                   /           |              \
      +--------------+  +--------------+  +-------------+
      | Planung1-DLL |  | Planung2-DLL |  |Planung3-DLL |
      +--------------+  +--------------+  +-------------+
             |        \ /       |      \ /         |
             |         X         |       X           |
             v         / \       v       / \         v
      +--------------+  +--------------+  +-------------+
      | DB-Planung1  |  | DB-Planung2  |  | DB-Planung3 |
      +--------------+  +--------------+  +-------------+

Im Prinzip soll das Programm versch. Forms der DLLs anzeigen. Die DLLs haben (in den meisten Fällen wohl) eine eigene DB. Jedoch muss es auch möglich sein, dass die DLLs auf die DBs der anderen DLLs zugreifen können. --> eine DB-Komponente ist wohl ausgeschlossen --> DLLs müssen wohl beim starten eine eigene DB-Komponente dynamisch anlegen

Dazu, was die DLLs können müssen:
- muss Mehoden exportieren --> ok
- muss Forms exportieren --> ok
- muss auf (versch.) Datenbanken zugreifen können --> PROBLEM!
-> müsste dynamisch Komponenten erstellen können ???
- 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

Die elementarsten Fragen sind damit wohl:
- Wie organisiert / strukturiert man am Besten den Datenbankzugriff?
- Wie lade ich ganze DLLs dynamisch? (vorhanden? -> laden, nicht vorhanden? -> nicht laden)

Zur letzten Frage: Müsste wohl so funktionieren, dass man versucht zu laden. Falls sie geladen wird, ist alles gut, falls eine Fehlermeldung zurückgegeben wird, überspringt man die. Müsste man sich wohl hauptsächlich anschauen, wie man das Programmtechnisch umsetzt.

Soweit zu meinen Gedanken...
Hoffentlich könnt ihr mir jetzt noch bessere Tipps geben!

Schonmal ein dickes Danke! hans ditter

[DeddyH]

Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis DLL-Tutorial ans Herz legen.

[Assarbad]

Zitat von DeddyH:

Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis DLL-Tutorial ans Herz legen.

Aaaah. Damit willst du mich nur zwingen es endlich zu aktualisieren, oder? War lange geplant, aber es finden sich weder Mitstreiter (trotz SF.net-Projekts als unabhängige Platform) noch Zeit.

Das was ich am meisten als Mißverständnis bei der Benutzung von DLLs sehe ist, daß die Leute DLLs oft als eigenständige Programme sehen. Das stimmt natürlich nicht. Aber um das zu verstehen muß man den Zusammenhang zwischen dem Code, einem Prozeß und den Threads in einem Prozeß erstmal begreifen. Da hakt es oftmals.

Ein Prozeß führt keinen Code aus, eine DLL auch nicht. Die DLL (wie auch die EXE) ist Container für Code und der Prozeß Container für Threads ... und die Threads führen den Code (quasi-)parallel (je nach Anzahl CPUs) aus. Im Endeffekt ist es absolut egal ob der Code der ausgeführt wird (sagen wir mal Quicksort) nun im Abbild der EXE oder im Abbild der DLL im Speicher liegt. Dennoch gibt es natürlich Einschränkungen, aber da muß ich auch auf ein leider etwas in die Jahre gekommenes Tutorial von mir verweisen, wie DeddyH auch schon.

Zitat von Blup:

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

Ich nehme an du meinst basierend auf IUnknown und Konsorten? Unterstütze ich in dem Fall voll.

Zitat von Blup:

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.

Hier würde ich eher noch weiter differenzieren und die Logik dazu welche Interfaces unterstützt werden eine Ebene unter der GUI ansiedeln.

Zitat von Blup:

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.

Das läßt sich a.) nicht für jeden Anwendungs-/GUI-Typ machen und b.) ist es nicht so clever wie es anfänglich klingt jeweils immer einzelne DLLs anzubieten. Für die Kernkompetenzen der Anwendung kann auch eine DLL mehrere Interfaces anbieten (über COM oder einen Mechanismus der den in COM nachbildet) für Erweiterungen würde ich wiederum mitgehen mit mehreren einzelnen DLLs ...

Zitat von Blup:

Dann wäre die Oberfläche komplett austauschbar (z.B. Web-Darstellung), ohne die eigentliche Anwendung zu beeinflussen.

Jetzt sind wir wieder beieinander.

[DeddyH]

Zitat von Assarbad:

Zitat von DeddyH:

Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis DLL-Tutorial ans Herz legen.

Aaaah. Damit willst du mich nur zwingen es endlich zu aktualisieren, oder?

Kleiner Wink mit dem Jägerzaun

[hans ditter]

Also, hoffe, dass ihr meine anderen Fragen weiter oben auch noch beantwortet, aber zunächst erstmal die wichtigeren Fragen:

1) Was genau ist mit Anwendungskern gemeint? Ist das so vorzustellen wie eine riesige Truhe, die alle Informationen über Komponenten und Klassen und Variablen und so weiter der Anwendung enthält?

2) Wie funktioniert das mit Interface? Was ich bisher verstanden hab ist, dass es sich dabei um eine Schnittstelle zwischen einer DLL und einem Aufrufprogramm handelt. ABER:
a) Wie funktioniert das? Wo ist der Sinn dieses Interface? --> Funktionsweise
b) Wie schreibe ich mir so ein Interface, bzw. mehrere Interfaces?
c) Welche Probleme kommen dabei auf mich zu?
d) KÖNNT IHR MIR EIN TUTORIAL EMPFEHLEN???

hans ditter

[hoda]

Hans Ditter warum sollen die DLLs jeweils eine eigene DBs haben?

Die Lösung von s.h.a.r.k ist 1a. Genau das ist auch meine Meinung. Ich kenne das von anderen Softwarelösungen, dass es eine DB gibt (MySQL,Access,SQL Express,usw.) auf den zugegriffen wird. Die DLLs stellen die Module dar, die der Kunde gekauft hat wie z.B. (Marketing, Lohn&Gehalt,usw.).
Wenn der Kunde eine dieser DLLs erworben hat, sieht er im Frontend seinen freigeschalteten Modul.
Ich gehe mal davon aus, dass du hier eher Tabellen meintest

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