DLL oder EXE

[Jasocul]

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.

[jaenicke]

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.

[QuickAndDirty]

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.

[Bernhard Geyer]

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.

[Bernhard Geyer]

Zitat von jaenicke:

Ein gutes Beispiel sind hier Google Chrome und Firefox.

Das ist aber ein schlechtes Beispiel.
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.

[Der schöne Günther]

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.

[Jasocul]

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.

[LTE5]

Zitat:

Ich bin ja auch eher der Freund einer kompakten großen Anwendung.

Ich ebenfalls.
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.

[Jasocul]

Zitat von LTE5:

... müssen bei einem Update die gesamten 20 MB heruntergeladen werden.

Das ist grundsätzlich auch zu bedenken, aber bei mir handelt es sich um Inhouse-Programme. Da wird kein Download benötigt.

[Delphi.Narium]

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.