5

我们有一些通用库（C#，但我想这不是特定于平台或语言的），我们称它们为 A、B 和 C。库 A 引用了 B 和 C，库 B 引用了第三方 DLL，库 C 独立。三个独立项目背后的想法是每个库都有不同的功能，但库 A 随着时间的推移已成为几乎每个客户端应用程序都引用的“包罗万象”的通用库。只有少数应用程序也引用了 B 和/或 C 而没有 A。

我们正在尝试改进我们的源代码控制约定，我们正在尝试做的一件事是正确标记和发布这些库 DLL，以便客户端项目文件可以指向代码的静态版本，而不是始终更改的主干。事实证明这有点令人费解——例如，一个同时引用 A 和 B 的客户项目。A 本身引用 B，因此从技术上讲，有两个对 B 的引用来自客户项目。

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

不过，这似乎太容易解决了，所以我想我至少会得到第二个意见。另一种方法是使用 GAC 并对所有内容进行强烈签名/版本。我在这里错过了什么吗？

4

7 回答 7

7

我认为您合并到一个库中是正确的。

代码经常被组件化为太多可部署的单元，而逻辑功能似乎是分离的标准。这是错误的国际海事组织。相反，程序集应与部署方案和发布周期保持一致。否则，您最终会得到一个极其复杂的依赖关系图，其中无论如何每个程序集都是一起管理、构建和部署的。

不过有趣的问题！让我们看看其他人的想法:)

于 2009-12-21T23:54:58.597 回答
3

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

您不想要一个单一的整体库 - 并且您不想要太多的库。您需要正确数量的库 :) 不多也不少，恰到好处。

有不同的库的原因：

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

我认为一般的经验法则可能是，如果有一个单独的团队致力于对库的特定部分进行全职开发，它应该是独立的。如果多个团队时不时地在这里和那里添加一些代码，那么开发和部署的独立性应该没有问题，您还不如拥有一个公共库。听起来您的情况就是这种情况，因此请使用单个库。

另一个要问的问题是“我们目前遇到的问题是拆分图书馆可以解决什么问题？” 如果它不能解决任何问题，则不需要单独的库。

于 2009-12-22T02:59:58.240 回答
2

观点 1
尽可能少的库可以简化构建脚本和部署（需要担心的部分更少）。拥有一个包含所有内部开发的 UI 组件的库非常适合启动新项目。只需添加一个参考，您就可以准备好所有内部组件。希望这可以减少重新发明组件所花费的时间，因为有人忘记了已经有一个包含此类组件的库。通用实用程序库也是如此——最好只有一个，这样您就可以通过一个参考获得所有可用的功能。

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

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

于 2009-12-22T00:20:19.310 回答
1

我同意为这些实用程序提供一个库是理想的，只要名称空间得到适当维护，并且代码本身被很好地分解，以便将来对库进行任何维护。我看到的主要理由正是您提到的，几乎所有内部​​应用程序都在使用它。

但是，要考虑的一件事是这些部件的功能。如果一个是用于使用控件或标签进行巧妙技巧的实用程序命名空间，第二个是处理您的登录过程的安全库，当“酷技巧 D”添加到实用程序库时，您可能会遇到一些意想不到的问题，但破坏了依赖于安全库的现有应用程序，但由于整个 DLL 现在已更新，因此被迫升级。

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

于 2009-12-22T00:07:20.613 回答
1

可能有理由为具有完全不同目的的库或引用第三方库的项目设置单独的项目。除此之外，您可以将大部分内容放在一个公共基础库中。

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

我们还有一个用于数据库 (MS SQL) 相关类的单独项目，但它确实可以进入公共库，因为我们很少有应用程序不使用数据库。

于 2009-12-22T00:11:41.010 回答
1

我会说这真的归结为最适合你的东西。一个大的 util 库可能很难在其中找到东西，但话又说回来，每个人都知道在哪里寻找它们可能会更有好处。同样取决于库的管理方式，不同的组可能更容易维护自己​​的 util 库（如果他们需要控制对它们的更改），但如果它由单个组管理（或者如果每个人都相处融洽）那么一个大一个可能更容易。所以真的什么都适合你。

于 2009-12-22T00:35:31.073 回答
1

只是分享一些最近的经验，这使我对此的观点略有改变......

将解决方案中的 150 个项目减少到大约 30 个，将我们的构建时间缩短到原来的 25%（1 分钟和更改，而在我们的典型开发机器上为 5 分钟）。如果您正在执行 dll 引用，那么这并不重要，但如果您将项目包含在主解决方案中，您可能会发现它很重要。老实说，我对这种差异感到有些惊讶，但过去的结果并不能保证未来的回报。

每次 .net 首次加载 dll 时，您都会承担 JIT-ing 和文件 I/O 开销。对于用户可能一天多次启动的 WinForm/WPF 应用程序，这比 Web 应用程序更令人担忧。即使对于 Winform/WPF 应用程序，对于许多应用程序来说也可能不是那么大的问题。

另一件需要注意的事情是复杂的依赖关系，这会导致“如果我使用 A，我必须使用 B，因为 A 暴露了 B 的类型。同时，我很少单独使用 B”只需将其组合并完成即可.

所以，我的理解是有一些具体的理由可以尝试巩固。可能有一百万个主观原因，但在一个大型解决方案文件中，尝试简单一点似乎更好，因为你可以合理地完成。

更主观地说，我还鼓励您将项目文件视为构建工件而不是代码工件。将 .cs 文件视为您真正想要重用的文件，而不是 .csproj。当然，大多数时候您也会重用 .csproj，并且始终以相同的方式构建程序集。但是，不要试图强迫自己拥有比项目实际需要更多的依赖项或代码。.csproj 和 .cs 之间的关系在大多数情况下是相当松散的。

编辑：@ - 添加“在你的项目中”

于 2009-12-22T00:01:54.023 回答