DLLs in komplexen Programm

[hans ditter]

Hallo liebe Gemeinde,

ich hatte vor einiger Zeit mal angefangen, sozusagen ein "Planungsprogramm" zu schreiben. Sollte eben in die Richtung gehen, dass man seine Ein- und Ausgaben, seine Aufgaben, Termine etc. pp. planen kann. Angefangen hab ich jetzt mit Ein- und Ausgaben und einer Übersicht für Arbeitsstunden.
Bitte keine Diskussion anfangen, ob das alles sinnvoll ist oder nicht!

Jetzt hab ich aber in meinem schönen dicken Delphibuch ein bisschen weitergelesen und hab endlich auch verstanden (hoffe ich zumindest ), wie das mit den DLLs funktioniert.
Da dachte ich mir, mach ich dieses Planungstool mal aus Modulen (mit DLLs).
Auch hier der Hinweis: Bitte keine Diskussion über Vor- und Nachteile von DLLs...

Leider hab ich jetzt aber ein Problem, mir auszumalen, wie man das alles vernetzen soll.

Ich geb mal zum Besseren Verständnis ein Beispiel, was ich meine:
Man hat das Modul "Ein- / Ausgabenplanung" (Modul 1) und das Modul "Arbeitsstunden planen" (Modul 2) installiert. Das Erstere von beiden erklärt sich von selbst. Beim Zweiten gibt man in einer Maske ein, von wann bis wann man gearbeitet hat, der Computer rechnet die Gesamtzeit und den Verdienst aus und speichert dies in einer Datenbank.
Nun soll aber das Modul 1 die Werte aus der Datenbank des Modul 2 mit einbeziehen, ergo soll Modul 1 automatisch am Ende des Monats den ges. Monatsverdienst aus dem Modul 2 mit in seine Datenbank integrieren.
Aber wie organisiere ich das jetzt? Wo sollen die Komponenten für den Zugriff auf die Datenbanken liegen, wie soll man auf diese zugreifen?

Im Moment liegen Datasource etc. noch auf der Mainform und beide Teilprogramme können darauf zugreifen, doch wie mache ich das, wenn ich diese beiden Teilprogramme in DLLs auslagere? Sollte ich dann für jedes Modul dynamisch eine Zugriffskomponente im Hauptprogramm anlegen, auf die dann zugegriffen werden kann?

Hoffe ihr könnt mir noch folgen,

frohe Adventsgrüße, hans ditter

[hoda]

Ich denke, dass es viele Wege gibt wie man das löst.Das Problem ist den richtigen zu nehmen.

Hier mein Vorschlag:
Eine Main Form, der das ganze Managet. D.h. der beinhaltet die Komponenten und lädt nur die DLLs hoch die auch tatsächlich vorhanden sind oder benötigt werden.

[Sir Rufo]

Zitat von hoda:

Hier mein Vorschlag:
Eine Main Form, der das ganze Managet. D.h. der beinhaltet die Komponenten und lädt nur die DLLs hoch die auch tatsächlich vorhanden sind oder benötigt werden.

Warum dafür eine/die MainForm genommen werden soll erschließt sich aber auch niemandem, da hier ja Funktionen aus DLLs angesprochen werden sollen, und die haben mit der GUI erstmal nix zu schaffen. Warum dann also das an ein GUI-Element verknüpfen bzw. ein GUI-Element zum Verwalten benutzen?

Eine einfache Unit, die diese Verwaltung übernimmt und gut

[hoda]

Zitat:

Warum dafür eine/die MainForm genommen werden soll erschließt sich aber auch niemandem...

Bei einem Planungsprogramm ist ein Frontend (Main Form) zwingend nötig. Wie soll die Interaktion mit dem User ansonsten stattfinden?
Es sei denn, es besteht bereits ein Client-Applikation, in dem man die DLLs hochladen will. Da gebe ich dir völlig Recht, dass dort ein Main Form unnütz ist.

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

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