为什么我不应该有一个单一的单片实用程序库？

Question

我们有几个常见的库（C＃但我认为这不是平台或语言特定的），我们称它们为A，B和C.库A引用了B和C，库B有一个引用第三方DLL，并且库C是独立的。三个独立项目背后的想法是，每个库都有不同的功能，但是随着时间的推移，库A几乎成为大多数每个客户端应用程序引用的“全部捕获”通用库。只有少数应用程序在没有A的情况下引用B和/或C。

我们正试图改进我们的源代码控制约定，我们正试图做的一件事是正确标记和释放这些库DLL，因此客户端项目文件可以指向代码的静态版本而不是始终 - 改变主干。这证明有点复杂 - 例如，引用A和B的客户端项目.A本身引用B，因此在技术上有两个来自客户端项目的对B的引用。

因此，显而易见的事情似乎只是将所有内容组合到一个具有良好组织的名称空间的公共/实用程序库中。正如我所说的，几乎每个客户端应用程序都引用这些库中的一个，那么谁在乎呢？这样做不会引入任何第三方依赖关系的不良情况，并且我们所有的目标机器都是内部的，并且保持大致相同的环境/软件配置。

虽然这似乎太容易解决，所以我想我至少会得到第二个意见。另一种方法可以是使用GAC并强制签署/版本。我在这里错过了什么？

Answer 1

我认为你是合并成一个单一的图书馆。

很多时候，代码被组件化为太多的可部署单元，而逻辑功能似乎是分离的标准。这是错误的IMO。组件应该与部署方案和发布周期保持一致。否则，最终会出现一个非常复杂的依赖关系图，无论哪个程序集都被管理，构建和部署在一起。

虽然有趣的问题！让我们来看看其他人的想法:)

Answer 2

公正地分享，才造成了我在看这一点上略有变化最近的一些经验...

减少150个项目在溶液中约30已经削减我们的构建时间约为原来的25％（1分钟，而我们的典型开发机器则为5分钟）。如果你正在做dll引用，那没什么关系，但是如果你在主要解决方案中包含这些项目，你可能会发现它很重要。说实话，我对这种差异感到有点惊讶，但过去的结果并不能保证未来的回报。

每次.net第一次加载dll时，您会承担JIT和文件I/O开销。对于用户每天可以多次启动它的WinForm/WPF应用程序，这是一个比网络应用程序更大的问题。即使对于Winform/WPF应用程序，它可能不是许多应用程序的一大问题。

要注意的另一件事是错综复杂的依赖关系，它会导致“如果我使用A，我必须使用B，因为A会暴露B的类型”。同时，我很少使用B。完成它。

所以，我的理解是有几个具体的原因来尝试巩固。可能有一百万个主观原因，但是在一个大型解决方案文件中，尽可能简单地尝试一下，因为你可以合理地拉下来。

更主观的是，我还鼓励您将项目文件视为构建工件而不是代码工件。考虑一下.cs文件，因为真的是想要重用，而不是.csproj。当然，大多数情况下你会重复使用.csproj，并且始终以相同的方式构建程序集。但是，不要试图强迫自己拥有比你的项目中实际需要的依赖性或更多的代码@。 .csproj和.cs之间的关系大部分时间是合理的。

编辑：@ - 增加了“在你的项目”

Answer 3

我同意，具有这些实用程序单个库是理想的，只要命名空间的正确维护和代码本身是很好的打破了今后的任何图书馆的维护。我看到的主要理由正是你提到的，几乎所有的内部应用程序都在使用它。

然而，有一点要考虑的是这些作品的功能。如果一块是用于使用控件或标签进行聪明技巧的实用程序名称空间，而另一块是处理登录过程的安全库，则当“酷技巧D”被添加到实用程序库时，可能会遇到一些意想不到的问题，但打破了依赖于安全库的现有应用程序，但由于整个DLL现在已经更新，所以被迫升级。

您可能会考虑以消除交叉依赖关系的方式重写所有三个库，并查看是否为您的当前和未来应用程序提供了更好的整体情况。

Answer 4

可能有理由针对完全不同目的的库或参考第三方库的项目分别开发项目。除此之外，您可以将大部分内容放在通用的基本库中。

我们有许多类的公共库，但是为Web相关类提供了一个单独的项目，一个用于PDF相关类的独立项目（因为它使用了我们不想在所有应用程序中使用的第三方DLL），一个用于MySQL相关类的独立项目（因为它使用第三方连接器）。

我们也有一个数据库（MS SQL）相关类的单独项目，但这可能真的进入了公共库，因为我们有这么几个应用程序不使用数据库。

Answer 5

查看点1
拥有尽可能少的库可简化构建脚本和部署（更少的部件需要担心）。拥有一个包含所有内部开发的UI组件的库对于启动新项目非常有用。只需添加一个参考，就可以准备好所有内部组件。希望能够减少重新构建组件的时间，因为有人忘记了已经有一个包含这样一个组件的库。与通用实用程序库相同 - 只有一个实用程序更好，因此您可以通过一个参考获得所有功能。

查看点2
将各种相关的功能分离为单独的库，使这些库保持专注并使其意图清晰。由于每个图书馆都更加专注，每个图书馆都会更小。因此，您的最终部署包可能会更小，因为您只包含实际需要的库。但是，您必须记住您拥有多少库以及每个库包含哪些库。这可能是文档和知识转移的噩梦。

那么，对你而言，部署规模或开发人员可用性更重要？选择优先级，然后将代码组织与其匹配。

Answer 6

我想说它真的只是归结为什么最适合你。一个大型的实用程序库可能很难找到其中的东西，但是这又一次在所有人都知道在哪里寻找它们可能会更有好处。另外，根据库的管理方式，不同的团队可能更容易维护他们自己的util库（如果他们需要控制对它们的更改），但是如果它由单个组管理（或者如果每个人都相处），那么一个大一个可能会更容易。所以真的适合你。

Answer 7

这是一个经典的“金发姑娘和三只熊”问题。

你不想要一个单一的整体库 - 而且你不需要太多的库。你只需要正确数量的图书馆:)不要太多，不能太少，恰到好处。

有具有不同的库的原因：

1）独立开发的 - 库可以独立开发。 2）更小的可部署

我认为，一般的经验法则可能是，如果有一个单独的团队专门在图书馆的特定部分进行全职开发，它应该是分开的。如果多个团队偶尔在这里或那几个地方添加一些代码，那么开发和部署的独立性应该没有问题，并且您可能只有一个公共库。听起来你的情况就是这样，所以去一个单一的图书馆。

另一个要问的问题是“我们目前遇到什么问题会导致图书馆解决问题？”如果它没有解决任何问题，那么不需要单独的库。