DLL oder EXE

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

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

[Jasocul]

Zitat von 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?

In der Regel, je nach Abteilung in unterschiedlicher Zusammensetzung. Es gibt nur wenige Überschneidungen gemeinsamer Module. Was aber meistens übergreifend gleich ist, sind die Auswahl-Fenster für die Datenbank-Kriterien (SQL-Statements).
Diese Fenster nerven mich am meisten, da es davon ein paar gibt, die für die meisten Anwendungen identisch sind.

Zitat von Delphi.Narium:

Handelt es sich bei den Inhouse-Programme eher um eine Applikation (zumindest aus Anwendersicht)?

Nein. Je nach Abteilung werden mehrere verschiedene Anwendung zur Verfügung gestellt. Ablageort ist ein File-Server und nicht die lokalen PC. I.d.R. gibt es eine Verlinkung auf dem Desktop.

Zitat von Delphi.Narium:

Eine Exe erscheint mir da deutlich einfacher in Bezug auf Pfleg- und Verteilbarkeit.

Ja und Nein. Wenn ich nur einzelne Forms (Auswahl-Fenster) anpassen möchte, kann ich einfach die DLL austauschen, ohne die Exe anzufassen. Die Exe muss dafür nicht mal neu kompiliert werden, solange die Aufruf-Konventionen sich nicht ändern. Das ließe sich mit Interfaces vermutlich sogar ziemlich flexibel gestalten.
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.

[Ghostwalker]

Zitat von Jasocul:

Diese Sub-Programme können dann durchaus auch einfach nur Auswahl-Fenster sein, die in verschiedenen anderen Programmen genutzt werden.

Öhm...also wer sowas in eine Exe auslagert, gehört sich meiner Meinung nach geteert und gefedert.

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

[Jasocul]

Zitat von Ghostwalker:

Öhm...also wer sowas in eine Exe auslagert, gehört sich meiner Meinung nach geteert und gefedert.

Jetzt weißt du, warum ich die Aktivitäten meines Vorgängers ändern will.

Zitat von Ghostwalker:

Alles andere kommt entweder in eine DLL (wenn die Funktionalität von mehreren unabhängigen Anwendungen gebraucht wird) oder ins Hauptprogramm.

Es ist halt die Frage, ob externe DLL oder externe Anwendung, aber:

Zitat von Ghostwalker:

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

Sowas will ich lesen, um mich bestätigt zu sehen
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.

[4dk2]

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

Meiner Meinung nach machen Aufteilung in mehrere Exen auch nur in wenigen Fällen Sinn.