Ist es eine gute Übung, eine Anwendung über mehrere EXE-Dateien zu erstellen?

Question

in einem Buch - ich denke, es war Eric S. Raymonds "die Kunst der Unix-Programmierung" - ich lese etw. So sollten Anwendungen erstellt werden, indem mehrere kleine Tools zusammengefügt werden.

Also würde ich gerne wissen, ob es eine gute Idee ist, eine Windows-Anwendung zu entwickeln, zum Beispiel, indem Sie eine kleine .exe für jede Aufgabe erstellen?

Zum Beispiel: Sie haben ein Dokument Managing System:

Diese zusammengestellt werden könnten wie:

• eine Exe für die Suche und Anzeige von Dokumenten (GUI)
• eine EXE für die Indizierung Dokument (Put-Dokumente in eine Datenbank)
• eine Exe zum Löschen von Dokumenten
• usw.

Denkst du, das wäre eine gute Idee oder sollte es in einer großen .exe mit mehreren DLLs (das wäre die Art, die ich sah die meisten Anwendungen gebaut)?

Was wären die Vor- und Nachteile?

Answer 1

Meiner Meinung nach:

Ja und nein. Einige Faktoren spielen eine Rolle, ob eine separate EXE-Datei erstellt werden soll oder nicht. Im großen Rahmen der Dinge müssen Sie entscheiden, ob die Aufgabe, die ausgeführt wird, eine eigene Datei garantiert. Ein großer Faktor ist, ob dies aus Ihrer zentralen Anwendung einen unabhängigen Zweck erfüllt oder nicht. Anschließend müssen Sie entscheiden, ob Ihre Anwendung in einem Paket lokalisiert ist oder ob es sich um eine Reihe von Dienstprogrammen handelt, die unabhängig voneinander verwendet werden können.

Aus der Sicht eines Benutzers mögen die Leute es nicht, wenn mehrere Programme gleichzeitig geöffnet sind. Gehen Sie zurück zu Ihrem Beispiel, hier ist, wie ich es tun würde. Ich würde für eine .exe wie das Hauptprogramm haben:

* an .exe for searching and displaying documents (GUI) 
* an .exe for deleting documents 
* etc. 

Und dann eine separate Exe haben, die als Hintergrund Indexer fungiert, die zweite Funktionalität durchführen, die Sie aufgelistet.

Wirklich, es sollte etwas von Fall zu Fall ausgewertet werden, unter Berücksichtigung eines intelligenten UI-Designs aus mehreren Perspektiven.

Edit: Auch Sie können sich in Situationen, wo alternative Mittel zur Trennung besser geeignet sind (dh Registerkarten, Dialogfelder, etc.)

Answer 2

Es gibt in der Tat viele Vor-und Nachteile, wenn wir die Granularität betrachten Komponenten, Dienste, bereitstellbare Einheiten usw.

In der traditionellen Befehlszeilen-Unix-Welt haben wir Daten in Form von Textdateien manipuliert, wobei jede Zeile ein Datensatz ist und möglicherweise Felder durch Kommas oder Tabulatoren oder Leerzeichen getrennt sind. Dann konnten viele kleine Utilities entwickelt werden und wir hatten riesigen Spaß mit "cut", "join", "tr", "grep", "sed", "head" usw. Ich persönlich stelle immer noch sicher, dass ich diese Werkzeuge habe in meinen Windows-Umgebungen.

Warum funktioniert das so gut? Ein grundlegendes Dateiformat agreemnt: Zeilen und Spalten. Wir können neue Dienstprogramme hinzufügen und wissen werden sie integrieren. Sie müssen nie ein altes Dienstprogramm ändern, weil wir ein neues hinzugefügt haben.Auch keine GUI, wir erwarten, an der Kommandozeile zu arbeiten. Wir starten nur Pipelines mit Aufgaben, um die Aufgabe zu erledigen.

Was machen Sie jetzt, wenn die Dinge komplizierter werden? Wenn Sie GUIs anbieten möchten. Einfacher Ansatz: Bisschen die Bullet Release eine einzige App. Neue Funktion, neue App-Version. Das ist vielleicht nicht so schlimm, Sie ändern einige Aspekte der Benutzeroberfläche, müssen einige Dateiformate oder APIs ändern, damit sich auch andere Teile ändern. Viel einfacher, ein einzelnes, kohärentes (vielleicht sogar) getestetes Ganzes zu veröffentlichen.

Aber wie der Umfang der UIs erhöhen, ist es ziemlich störend, alles zu veröffentlichen. Daher die Herausbildung von Komponentenmodellen wie OSGi, die von Eclipse ausgenutzt werden, so dass eine einzelne Benutzeroberfläche aus vielen separat entwickelten und sich entwickelnden Teilen zusammengesetzt werden kann.