Architecture 通过多个.exe编写应用程序是一种好的做法吗？

在一本书中——我想是Eric S.Raymonds写的《unix编程的艺术》——我读到了这样的内容：应用程序应该通过将多个小工具组合在一起来构建

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

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

这可以放在一起，如：

• 用于搜索和显示文档的.exe（GUI）
• 用于索引文档的.exe（将文档放入数据库）
• 用于删除文档的.exe
• 等等

您认为这是一个好主意吗？还是应该将它放在一个带有多个DLL的大型.exe中（这将是我看到的大多数应用程序构建的方式）

利与弊是什么？

在我看来：

是和否。决定是否应该创建一个完全不同的.exe有几个因素。在大计划中，您必须决定正在执行的任务是否需要自己的文件。决定这一点的一个重要因素是它是否独立于您的中心应用程序。接下来，您还必须决定是将应用程序本地化到一个包中，还是一系列可以独立使用的实用程序中的一个或多个

从用户的角度来看，人们不喜欢同时打开多个程序。回到你的例子，我会这样做。我将使用一个.exe作为主程序，用于：

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

然后有一个单独的.exe作为后台索引器，执行您列出的第二个功能

实际上，它应该是基于具体情况进行评估的，并从多个角度考虑智能UI设计

---

<>编辑：同样，您可能会发现，在可选的分离方法更适合的情况下（即标签、对话框等）

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

为什么这个工作这么好？基本文件格式：行和列。我们可以添加新的实用程序，知道它们将集成。永远不需要更改旧的实用程序，因为我们添加了一个新的实用程序。也没有GUI，我们希望在命令行上工作。我们只是启动任务管道来完成工作

当事情变得更复杂时，你会怎么做？当您想要提供GUI时。简单的方法：直接发布一个应用程序。新功能，新应用版本。这可能没那么糟糕，您更改了UI的某些方面，需要更改一些文件格式或API，所以其他部分也会更改。更容易发布一个单一的、连贯的（甚至可能）测试过的整体

---

然而，随着UI范围的扩大，发布所有内容会造成相当大的破坏。因此出现了组件模型，如Eclipse开发的OSGi，这样就可以从许多单独开发和发展的部分组装单个UI。

您完全没有注意到这种分离。这都是关于自动化的，如果你没有方法（例如脚本语言）来编写更高级别的解决方案，那么分离这些程序是毫无意义的，尤其是在谈到GUI时。