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

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.程序集应与部署方案和发布周期保持一致.否则,您最终会得到一个非常复杂的依赖图,无论如何,每个程序集都会被管理,构建和部署在一起.

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