为什么我不应该有一个单一的整体效用库？ [英] Why shouldn't I have a single monolithic utility library?

问题描述

我们已经有了一些常见的库（C＃，但我想这是不是与平台或特定语言），我们姑且称之为A，B和C库有B和C的引用文件，库B已到第三方的DLL和库C基准是独一无二的。后面的三个独立的项目，当时的想法是，每个库有不同的功能，但库中已经随着时间的推移变得或多或少的一揽子公共库，每一个客户端应用程序引用最多。只有少数应用参考B和/或C没有一个为好。

We've got a few common libraries (C# but I guess this isn't platform- or language-specific), let's call them A, B, and C. Library A has references to B and C, library B has a reference to a 3rd-party DLL, and library C stands alone. The idea behind three separate projects was that each library had distinct functionality, but library A has over time become a more or less "catch-all" common library that most every client app references. Only a few apps reference B and/or C without A as well.

我们正在努力改善我们的源代码控制公约，而且我们正在努力做的一件事正确标记和释放这些库DLL文件，所以客户端项目文件可以指向代码，而不是总是变化的躯干的静态版本。这被证明是一个令人费解的一点 - 例如，引用A和B. A本身引用B中的客户端项目，所以有技术上的两个引用到B，从客户端项目未来

We're trying to improve our source control conventions, and one thing we're trying to do is properly tag and release these library DLLs, so client project files can point to a static version of the code instead of the always-changing trunk. This is proving a bit convoluted - for example, a client project that references both A and B. A itself references B, so there are technically two references to B coming from the client project.

所以，显而易见的事情似乎只是一切都合并成精心组织命名空间一个共同的/实用程序库。正如我所说的，几乎每一个客户端应用程序引用这些库之一，所以谁在乎呢？这样做会不会引入与第三方的依赖任何不良的情况下，我们的所有目标机器内部，保持大致相同的环境/软件配置。

So the obvious thing seems to be to just combine everything into a single common/utility library with well-organized namespaces. As I said, almost every client app references one of these libraries, so who cares? Doing this won't introduce any undesirable situations with 3rd-party dependencies, and all our target machines are internal and maintain roughly the same environment/software configuration.

这似乎太简单的解决办法的了，所以我想我至少可以得到第二个意见。一种替代办法是使用GAC和强烈签名/版本的一切。我错过任何捕捉在这里？

This seems too easy of a solution though, so I figured I'd at least get a second opinion. An alternative could be to use the GAC and strongly sign/version everything. Am I missing any catches here?

推荐答案

我觉得你说得对合并到单个库中。

I think you're right consolidating into a single library.

往往码被组件化到太多部署单元，而功能性的逻辑片似乎是分离的标准。这是错误的海事组织。大会应与部署方案和释放周期，而不是对齐。否则，你结束了一个可怕的复杂的依赖关系图，其中每反正装配管理，构建和部署在一起。

Very often code is componentized into too many deployable units whereas the logical piece of functionality seems to be the criteria for separation. This is wrong IMO. Assemblies should be aligned with the deployment scenarios and release cycles instead. Otherwise you end up with a horribly complex dependency graph where anyways every assembly is managed, built and deployed together.

有趣的问题，但！让我们来看看其他人的想法：）

Interesting question though! Let's see what other people think :)

这篇关于为什么我不应该有一个单一的整体效用库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！