architecture - 通过多个 .exe 编写应用程序是一种好习惯吗？

Question

关闭。这个问题是off-topic .它目前不接受答案。












想改进这个问题？ Update the question所以它是on-topic对于堆栈溢出。

10年前关闭。




Improve this question




在一本书中-我认为这是 Eric S. Raymonds “unix 编程的艺术”-我读过某事。像这样的应用程序应该通过将多个小工具放在一起来构建。

所以，我想知道开发一个windows应用程序是否是个好主意，例如，为每个任务创建一个小的.exe？

例如:您有一个文档管理系统:

这可以像这样放在一起:

用于搜索和显示文档 (GUI) 的 .exe

用于索引文档的 .exe(将文档放入数据库)

用于删除文档的 .exe

等

您认为这是一个好主意还是应该将其放入一个带有多个 DLL 的大 .exe 中(这将是我看到大多数应用程序构建的方式)？

有什么好处和坏处？

Answer 1

当我们考虑组件、服务、可部署单元等的粒度时，确实有很多优点和缺点。

在传统的命令行 unix 世界中，我们以文本文件的形式处理数据，每一行都是一条记录，并且可能包含由逗号、制表符或空格分隔的字段。然后可以开发很多小实用程序，我们在“cut”、“join”、“tr”、“grep”、“sed”、“head”等方面玩得很开心。就个人而言，我仍然确保我拥有这些工具在我的 Windows 环境中。

为什么这个效果这么好？一个基本的文件格式协议(protocol):行和列。我们可以添加新的实用程序和 了解他们将整合。永远不需要更改旧实用程序，因为我们添加了新实用程序。也没有 GUI，我们希望在命令行下工作。我们只是启动任务管道来完成工作。

现在，当事情变得更复杂时，你会怎么做？当您想提供 GUI 时。简单的做法:硬着头皮发布一个App。新功能，新应用版本。这可能还不错，您更改了 UI 的某些方面，需要更改某些文件格式或 API，因此其他部分也会更改。发布一个单一的、连贯的、(甚至可能)经过测试的整体要容易得多。

然而，随着 UI 范围的扩大，发布所有内容是相当具有破坏性的。因此出现了组件模型，例如 Eclipse 所利用的 OSGi，因此单个 UI 可以由许多单独开发和发展的部分组装而成。