|
DLL oder EXE
Einer meiner Vorgänger war Delphi-Autodidakt und hat einzelne Programmmodule in verschiedene Programme aufgeteilt. Der Aufruf geht dann über ein Shellexecute und Parameter-Übergabe.
Das funktioniert auch alles problemlos, aber irgendwie kann ich mich damit nicht anfreunden. Nun überlege ich, ob man dieses Konstrukt nicht auf DLL umstellt, bin mir aber über die Vor- und Nachteile noch nicht im klaren. Da ich glaube, dass solche Überlegungen und Abwägungen von grundsätzlichem Interesse sein könnten, stelle ich das hier zur Diskussion. [EDIT] Nach abgeschlossener Diskussion würde ich natürlich die Diskussions-Ergebnisse zusammengefasst bereitstellen. |
AW: DLL oder EXE
Ein Vorteil ist, dass du dich um Multithreading nicht kümmern musst, da alles in separaten Prozessen abläuft.
Außerdem ist die Stabilität höher, da Fehler in einem Modul sich nicht direkt auf die Hauptanwendung auswirken und diese ggf. zum Absturz bringen. Ein gutes Beispiel sind hier Google Chrome und Firefox. In Chrome stürzten in den ersten Versionen schonmal Addons oder Tabs ab, aber die anderen Tabs oder gar das ganze Browserfenster waren nicht betroffen. Dadurch passierte dabei nicht viel, es ging halt schnell weiter. Bei Firefox hingegen reichte es, wenn ein Addon abgestürzt war, schon war der ganze Browser weg und damit ggf. auch eingegebene Daten usw. (deren Zwischenspeicherung kam ja erst als das in Chrome schon selbstverständlich war). Ein weiterer Vorteil ist, dass man die "Schnittstelle" sehr gut erweitern kann und sogar unbekannte zusätzliche Übergabeparameter konfigurieren könnte ohne dass die Hostanwendung weiß was diese machen bzw. diese dort eingebaut werden müssen. Nichtsdestotrotz benutze ich auch lieber DLLs mit einer universellen interfacebasierten Schnittstelle. |
AW: DLL oder EXE
Ich weiß von einer Wawi die haben auch jedes Fenster (Personal, Artikel, Aufträge, Rechnungen, %c.) als eigene Exe umgesetzt.
Ich denke, dass das eine gute Sache bei Clients von Client-Server Anwendungen und bei Fatclients von Datenbank Anwendnungen ist! Unter Linux ist es sogar recht üblich statt eines Threads aufzumachen einen Fork des Prozesses zu starten. Auch Windows kann das, seit Windows NT. Allerdings habe ich das persönlich auch nie so gelöst. |
AW: DLL oder EXE
Ich bin eher ein Freund einer großen Exe. Damit ersparts du dir z.B. die sogenannte DLL Hölle.
Auch ist deine Anwendung viel kleiner wenn du statt 100 DLLs mit je 5 MB nur noch eine Exe mit 10 MB hast. Vor Jahren (als es noch Disketten gab) habe ich mal eine solche DLL-Hölle aufgelöst. Die alte Lösung war das jeder "Furz" in eine DLL ausgelagert wurde. Die Lösung wurde auf mehrer Disketten ausgeliefert. Nach Umbau gabs nur noch eine Exe. Die Lizenzfrage war eh über HW gelöst, die nötig war um die Funktion zu besitzen. |
AW: DLL oder EXE
Zitat:
Firefox hat fast alle Browserfunktionalität in einer 70 MB großen DLL, Chrome in einer 50 bzw. 60 MB großen DLL. Die Aufteilung in DLls für jede Funktion ist etwas anderes als der Start neuere Prozesse für einzelen Tabs. |
AW: DLL oder EXE
Ich bin kein Freund der Multi-Prozess-Lösung. Als Beispiel werden immer gerne die Webbrowser angeführt. Hier passt das schön weil jeder Tab im Endeffekt die gleiche Aufgabe hat. Bei einer Software mit einzelnen "Programmmodulen" wirst du für jeden Teil wohl unterschiedliche Aufgaben und Schnittstellen haben.
Die Stabilität wie ein Tab abstürzen kann wird immer gerne angeführt. Ein isolierter Tab in einem Browser kann gerne abstürzen - Ist es in deinem Programm auch so vorgesehen dass Modul X abstürzt und sich selbst neu startet? Oder handelt man sich damit im Endeffekt noch mehr Arbeit ein? Vielleicht liegt es daran dass wir damit auf die Nase gefallen sind, aber der Aufwand die ganzen Schnittstellen zwischen den Prozessen zu bauen und zu prüfen ist ein ganz anderer als wenn du alles in einer Anwendung mit einem Quelltext hast. Ganz zu schweigen vom Debugging, mit Delphi hat das echt keinen Spaß gemacht mehrere Prozesse gleichzeitig zu debuggen, warum sich Prozess B so verhält, was muss er vorher von Prozess A für Daten empfangen haben muss, usw. TL;DR: Ich bin auch der Freund eines zentralen, übersichtlichen Programms. Solange es nicht explizit Teil des Plans ist dass der Nutzer einzelne Bestandteile gegen andere Implementierungen austauschen können soll (.DLL) sehe ich keinen Grund das künstlich so aufzusplitten. |
AW: DLL oder EXE
Ich bin ja auch eher der Freund einer kompakten großen Anwendung.
Es gibt aber prinzipiell mehrere kleinere Basis-Programme, damit es kein völlig überfrachtetes Hauptprogramm gibt, das zu allen anderen Programmen verzweigt. Mal abgesehen davon, dass keine Abteilung alle Menüpunkte benötigt. Das könnte man sicher über ein Berechtigungskonzept lösen, ist hier aber nicht das Thema. Diese Einzelprogramme rufen dann andere Programme auf. Diese Sub-Programme können dann durchaus auch einfach nur Auswahl-Fenster sein, die in verschiedenen anderen Programmen genutzt werden. An der Stelle möchte ich gerne ansetzen und stelle deshalb diese Überlegungen mit DLL/EXE an. Natürlich könnte man auch eine entsprechende Basis-Form definieren und davon ableiten. Jedoch müssten bei einer Änderung alle betroffenen Anwendungen erneuert werden. Die Auslagerung ist also prinzipiell eine gute Idee (meine Meinung). Derzeit wird das Sub-Programm aufgerufen, dass dann je nach Auswahl-Ergebnis ein weiteres Sub-Programm aufruft. Das alles wird über Parameter-Übergabe gesteuert. Wenn ich aber eine DLL dafür nutzen würde, könnte ich ein entsprechendes Interface definieren und käme nach der Auswahl wieder zurück ins aufrufende Programm und kann dort steuern, was als nächstes aufgerufen wird. Dadurch verliere ich mich nicht Sub-Sub-Sub-...-Programmen. Bei Änderungen könnte ich einfach die DLL austauschen. Natürlich kann ich auch eine EXE austauschen. Ich bin mir einfach nicht sicher, was die bessere Lösung ist. |
AW: DLL oder EXE
Zitat:
Wenn so eine große Anwendung dann aber 20 MB hat und sich nur eine kleine Funktion ändert, müssen bei einem Update die gesamten 20 MB heruntergeladen werden. Hier hätte eine große DLL, mit allen Funktionen, den Vorteil, dass man weniger herunterladen muss. Jedenfalls ist das meine Vermutung. |
AW: DLL oder EXE
Zitat:
|
AW: DLL oder EXE
Frage: Werden die einzelnen Programmteile (alle oder einige) auch einzeln benötigt oder immer nur alles zusammen? Oder je nach Arbeitsplatz in unterschiedlicher Zusammensetzung?
Handelt es sich bei den Inhouse-Programme eher um eine Applikation (zumindest aus Anwendersicht)? Dann würd' ich so peu à peu, wie es sich ergibt, daraus eine einzige Exe machen. Bei Änderungen muss dann nur genau die zur Verfügung gestellt werden und man muss nicht darauf achten, ob an jedem Arbeitsplatz auch immer die richten Exen zusammen liegen bzw. die richtige Exe mit den entsprechenden DLLs und man muss auch nicht mehr darauf achten, ob man auch immer überall alle entsprechenden Exen und DLLs (in passender Kombination) ausgetauscht hat. Eine Exe erscheint mir da deutlich einfacher in Bezug auf Pfleg- und Verteilbarkeit. |
AW: DLL oder EXE
Zitat:
Zitat:
Wir benutzen auch mehrere DLLs. Die kann man per Konfiguration einklinken und stellen Interfaces usw. zur Verfügung. Man kann solch eine DLL aber auch in ein Testprogramm einklinken und diese dort separat von dem Hauptprogramm testen. Insgesamt finde ich das flexibler als eine große Anwendung. Zumal wir damit auch die Möglichkeit haben, dass jemand von außen eine passende DLL schreibt und die Funktionalität nutzt statt nur auf Skripte usw. beschränkt zu sein (so umfangreich die auch sind). |
AW: DLL oder EXE
Zitat:
Diese Fenster nerven mich am meisten, da es davon ein paar gibt, die für die meisten Anwendungen identisch sind. Zitat:
Zitat:
Oder wenn eine Tabellen-Übersicht angepasst wird, kann das auch ohne Austausch der Exe durchgeführt werden. Der Pflege-Aufwand kann vermutlich größer werden. Der Verteil-Aufwand ist gering, da die Anwendungen zentral abgelegt sind. Die DLLs wären das dann dementsprechend auch. |
AW: DLL oder EXE
Zitat:
Eine eigenständige Exe macht nur dann Sinn, wenn ich a) Das Programm unabhängig vom Hauptprogramm nutzen können soll b) und/oder es sich um eine Arbeit handelt, die länger dauern kann und ich dem Anwender unterdessen die Arbeit mit dem Hauptprogramm erlauben möchte (Multitasking/-threading) Alles andere kommt entweder in eine DLL (wenn die Funktionalität von mehreren unabhängigen Anwendungen gebraucht wird) oder ins Hauptprogramm. Neben der Ergebnis- und Parameterschubserei, die bei einer Exe doch etwas komplizierter ausfällt, als bei einer DLL, gibts auch viele arbeiten, die doppelt gemacht werden müssen (z.B. Aufbau Datenbankverbindung, Übersetzungssystem...). Beim arbeiten mit DLL's und Interfaces hab ich dagegen schonmal den Vorteil, das zumindest schonmal die Typen der Parameter richtig sein müssen (sonst meckert ja der Compiler). Von Sicherheitsaspekten will ich noch nicht mal reden :) |
AW: DLL oder EXE
Zitat:
Zitat:
Zitat:
Meine letzte selbst programmierte DLL ist schon viele Jahre her. Mit dieser Diskussion hoffe ich, dass ich das Für und Wider richtig berücksichtige. |
AW: DLL oder EXE
Es gibt dann ja auch noch die Möglichkeit die Kommunikation zwischen zwei Anwendungen per Dll zu lösen:
EXE<->DLL<->EXE Ich kann aus persönlicher Erfahrung dann empfehlen, bei Delphi bloß nicht versuchen Objekte auszutauschen :lol: Meiner Meinung nach machen Aufteilung in mehrere Exen auch nur in wenigen Fällen Sinn. |
AW: DLL oder EXE
[QUOTE=4dk2;1388578
Ich kann aus persönlicher Erfahrung dann empfehlen, bei Delphi bloß nicht versuchen Objekte auszutauschen :lol: [/QUOTE] Nicht nur bei Delphi. Der Austausch von Objekten zwischen Exe/Dll ist auch in anderen Sprachen nicht wirklich möglich. Dazu brauchst du dan COM oder du benutzt (wenn es nur um Delphi geht) BPL's (  BPL). |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 04:24 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-2025 by Thomas Breitkreuz