![]() |
AW: DLLs in komplexen Programm
Im Prinzip geht es doch darum, das alle Teile möglichst unabhängig von einander funktionieren.
Darum würde ich Interface einsetzen. Zitat:
Zitat:
Eigentlich braucht man ja nur die Verbindungsparameter z.B. als Connectstring weiter zu geben. Zitat:
Zitat:
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:
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.
+----------------+ +--------------+--------------+
| | -- | Interface | GUI | | | +--------------+--------------+ | | | | +--------------+--------------+ | | -- | Interface | Planung1-DLL | | | +--------------+--------------+ | Anwendungskern | | | +--------------+--------------+ | | -- | Interface | Planung2-DLL | | | +--------------+--------------+ | | | | +--------------+--------------+ | | -- | Interface | Planung3-DLL | +----------------+ +--------------+--------------+ Dann wäre die Oberfläche komplett austauschbar (z.B. Web-Darstellung), ohne die eigentliche Anwendung zu beeinflussen. |
AW: DLLs in komplexen Programm
Wow, gute Antworten... aber damit bin ich grade überfordert... :oops:
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...:oops: Ich freue mich auf eure Antworten! schneeige Grüße, hans ditter |
AW: DLLs in komplexen Programm
Zitat:
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:
![]() Zitat:
Zitat:
Zitat:
|
AW: DLLs in komplexen Programm
Zitat:
|
AW: DLLs in komplexen Programm
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??? :pale: :shock: hans ditter |
AW: DLLs in komplexen Programm
Ich werfe hier einfach mal den Begriff Framework in die Runde: Werf.
Es gibt schon fertige Frameworks die schon ein fertiges Pluginsystem anbieten. Man muss also das Rad nicht neu erfinden. Ich bin mir nicht sicher, aber ich glaube von RemObjects gibt es so ein Fraework. Jedenfalls habe ich schon mal mit so einem fertigen Pluginsystem gearbeitet. In der Firma auf meinem Rechner habe ich sogar eine selbst geschriebene Anwendung liegen, die Plugins nutzt. Nur leider werde ich das nächste viertel Jahr da nicht drankommen. @Olli: Schreib mir mal, was an deinem Tutorial gemacht werden soll. Eventuell kann ich das ein oder andere Kapitel beisteuern. Ich würde sie dir dann auch in Latex liefern können. Was Prozesse, Threads und den Kram angeht habe ich schon was fertiges auf der Platte liegen. |
AW: DLLs in komplexen Programm
Hmm, leider kann ich bisher mit keiner Antwort so richtig was anfangen... :(
Ihr bombardiert mich mit Begriffen, die mir ein wenig unbekannt sind: - Framework - Interface - Callback . . . Also, ich habe bisher verstanden, dass: - ich eine DLL, eine GUI und eine Unit habe, die beides miteinander kommunizieren lässt - ich für die Kommunikation irgendwie Interfaces benutzen soll, weil das ein Vorteil birgt (??) ... - es noch eine Unit / oder in der Management-Unit noch einen Teil geben sollte, der die Interfaces verwaltet... - es "exorbitant wichtig ist", sich vorher klar darüber zu sein, was das Modul können soll und was es dafür braucht - es auch noch eine Möglichkeit mit Frameworks gibt... Leider ist das alles sehr theoretisch, und unter vielem kann ich mir nicht richtig was vorstellen. Z.B. Interfaces: Ich hab schonmal danach gegoogelt, hab mir den Link zu IUnknown angeschaut und auf der Seite auch noch nach Interface gesucht, hatte hinterher aber ungefähr genausoviel Ahnung wie vorher. Es würde mir (denke ich) schonmal helfen, wenn ihr mir etwas Starthilfe geben könntet. Starthilfe im Sinne von: Sollte ich jetzt als erstes Mal die DLL komplett schreiben? Oder doch lieber das Ganze erstmal auf Papier theoretisch bearbeiten und dann gleick komplett umsetzen? Wo kann ich Grundwissen zu Interfaces, Frameworks und Callbacks bekommen? Wie fange ich jetzt am Besten an? Es würde mir auch helfen, wenn ihr die Fragen, die ich in vorigen Threads schonmal gestellt hab nochmal beantworten könnt. Ich hab zumindest keine direkte Antwort auf irgendeine dieser Antworten gefunden. Falls ich mir irre, bitte drauf hinweisen, dann schau ich mir den Post nochmal genauer an!! Danke, hans ditter |
AW: DLLs in komplexen Programm
Hallo Hans Ditter,
Unter folgendem Link findest Du eine recht schöne Erklärung zum Einsatz von Interfaces für die PlugIn-Realisierung. Beim Suchen in Delphi-Praxis habe ich bisher stets schnell Lösungen zu meinen Problemen gefunden. :thumb: Ansonsten hilft ofmals auch ein kleiner Blick in die recht umfangreiche Online-Hilfe von Delphi und ggf. ein Blick in die Sprachreferenz und deren mitgelieferte Anleitungen und Beispielen. :idea: Ich kann in dieser Hinsicht nur zu Geduld und Lesebereitschaft aufrufen. Bin selbst bereits seit einiger Zeit Mitglied in der DP und musste bisher noch keine Frage selbst stellen. ![]() |
AW: DLLs in komplexen Programm
Hallo Hans Ditter,
Zitat:
Imho bringt es dir nichts eine Planung zu erstellen wenn dir der Sinn und die Funktionsweise bestimmter 'Mechanismen' nicht klar sind. Zerlege deine Problemstellung in kleine Teileinheiten und arbeite diese nacheinander ab. In der Regel probiere ich neue Sachen dann zunächst in kleinen Testprojekten aus - um wirklich zu verstehen wie was funktioniert... ![]() |
AW: DLLs in komplexen Programm
Hallo Hans Ditter,
ich schließe mich Rapante an. Am besten ist es, wenn Du Dich erstmal hinsetzt und aufschreibst was Dein Programm können soll. Male Dir mal ein paar Use-cases auf (Anwendungsfälle, die Du Dir mit dem Programm vorstellst) und entwickle daraus die Anforderungen, die Du an das Programm stellst. Daraus ergeben sich schließlich kleine Teilbereiche, die Du dann genau planst und Schritt für Schritt realisierst. Ich weiß selbst wie es ist, wenn man darauf brennt gleich "loszulegen" und ein kleines Programm zu schreiben. Später hast Du dann sehr viel Arbeit alles in logische Teileinheiten zu sortieren udn diese wiederum sinnvoll miteinander zu verknüpfen. An Fehlersuche und Erweiterungen gar nicht zu denken. Und mal ganz ehrlich, es kann auch wirklich Spass machen ein Programm genau durchzuplanen. Dabei lernt man sehr viel über das Vorgehen der Profis und man wird schnell feststellen, dass dann die Umsetzung viel frustfreier vonstatten geht. Viele Grüße, Marc |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:23 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz