如何决定何时实现DLL？

在哪一点上，您决定将一些子例程和公共代码放在类库或DLL中？在我的一个应用程序中，我想在不同的项目之间共享我的一些通用代码（我们都知道，这是一个很好的例子）

我的绝大多数代码都在一个项目中。我还有一个小实用程序，它是从主可执行文件中分割出来的，主可执行文件以提升的权限运行，只用于一个目的。这两项最多有三个共同的子程序。这些公共子例程是否应该从类库中放置和调用？您如何决定何时执行此操作？当您至少有一个共享子例程时？二十多行代码

---

我不认为这应该是特定于语言或依赖于框架的，但如果是这样，我使用的是.NET framework。

如果代码在多个应用程序之间共享，那么它必须驻留在DLL或类库中

对于更大的应用程序，您可能还希望将应用程序的不同子系统拆分为单独的库。这样，每个项目都可以专注于一项特定的任务。这简化了应用程序的结构，并使查找任何一段代码变得更容易。例如，您可能有一个具有不同DLL（.NET项目）的GUI应用程序，用于：

• 使用特定的网络协议
• 访问公共代码，例如实用程序类
• 访问旧代码（通过PInvoke）
• 等等

---

在应用程序之间共享代码的方式比使用DLL的方式更多。从它听起来的样子来看，你没有谈论太多的代码，所以听起来你不需要太担心它

通常，我使用以下经验法则：

• 对于简单的代码复制（两个简单的1-2行函数，易于理解和调试），我将复制并粘贴代码

• 对于更复杂的函数（包含在一两个文件中的独立助手函数的小型库，需要适度的维护和调试），我只需将该文件包含在两个项目中（通过链接或定义子存储库之类的方式）

• 为了实现更广泛的代码共享（一组相互关联的类，或者一个数据库通信层，这对多个项目很有用），我将把它们重构成一个独立的库，并使用适合于我正在编程的任何东西来打包和分发它们

因为管理代码的复杂性在每个步骤中都会增加一个数量级（当您为多个项目打包DLL时，您现在需要考虑版本控制问题），所以您只想在需要时进入下一个级别。听起来您还没有感受到处理公共代码的痛苦，如果是这样的话，就没有真正的需要了