多个小组件或一个大组件哪个更好？答案

【问题标题】：What is better, many small assemblies, or one big assembly?多个小组件或一个大组件哪个更好？
【发布时间】：2009-02-20 08:51:36
【问题描述】：

一切尽在标题中:)

目前，我们有 20 多个项目的 VS2005 解决方案。喜欢

MySolution
MySolution.Modules.Foo
MySolution.Modules.Bar
[insert many here]
MySolution.Modules.Baz

在一个项目中“合并” MySolution.Modules.* 会有什么危害吗？所有的命名空间都会被保留，所以这里没有问题。

但是有什么我没有想到的吗？

注意：目前，不能有循环引用：如果 MySolution.Modules.Foo 引用 MySolution.Modules.Bar，MySolution.Modules.Bar 不能引用 MySolution.Modules.Foo。所以我们必须小心不要创建一些。

【问题讨论】：

标签： .net

【解决方案1】：

我曾在几家公司工作过，因为项目太多，从各个方面来说都是一种痛苦。我还没有到过任何很少项目的地方，尽管这当然是可能的。

除其他外，将项目视为一个可重用单元。是否有任何产品需要 Foo 而不需要 Bar，反之亦然？如果没有，请将它们合并在一起。

我喜欢将不同的层（表示、业务逻辑、数据访问）分开，拥有一个通用的、与产品无关的实用程序库很好，但在很多情况下就是这样。

哦，当然，将测试保存在与生产代码不同的项目中：)

【讨论】：

另一方面，领域驱动设计会激发代码的垂直拆分。
@Slampen：我没有足够的 DDD 经验。
我认为，如果所有小项目都集中在一个大项目中，那么您所遭受的痛苦就会被隐藏起来。

【解决方案2】：

一个组件的优点：

潜在性能
可能更容易部署

许多组件的优点：

其他所有内容。假设这些是良好的内聚模块，它有助于分离关注点，通过迫使您考虑架构的水平/分层等来检查依赖关系。

【讨论】：

拥有许多小程序集不会降低 Visual Studio 的性能吗？在创建元数据和调试符号时，不是每个单独的程序集都有开销吗？

【解决方案3】：

我们使用ILMerge 将我们所有的小程序集绑定到一个更大的块中。尤其是位于不同项目中但最终属于同一名称空间的程序集。

例如，我们有很多用于记录和视图的数据实体，分布在多个程序集、MJ.DE.views.dll、MJ.DE.tables.dll、MJ.DE.sprocs.dll 等，但在最后我们使用 ILMerge 将它们绑定到一个单独的 MJ.DE.DLL 中。 - 使更新/同步应用程序更容易，因为生产服务器上需要处理的部分更少，而且我们知道所有相关的类都来自同一个编译。

【讨论】：

【解决方案4】：

编译时间。如果您将项目分解为多个部分，则只需编译已修改的部分。如果它是一个大项目的一部分，那么每次更改某些内容时都必须重新编译所有内容。根据您的项目有多大，这可能很重要。

【讨论】：

我从未见过这对于 C# 项目来说是一件大事。相反，MSBuild 开销有时似乎比 C# 编译器重。（顺便说一句，这完全是轶事证据。）

【解决方案5】：

一方面，如果您有大量项目，Visual Studio 加载解决方案的时间就会越来越长，而不是少数项目中有大量代码。

这不一定是一个足够好的理由只拥有一个项目，而不是这里提到的所有其他项目，但要记住一些事情。

【讨论】：

我以前听说过，但从未体验过。你能定义“吨”吗？我有一个包含 50 个以上项目的解决方案，它的加载速度非常快。
可能还涉及其他因素。我们正在使用 TFS，它可能会花时间刷新源代码控制状态，但我们的解决方案包含 45 个项目，并且在最坏的情况下可能会花费 30 秒的时间来加载。当然，不多，但测试表明这与项目数量有关。
@Kent，我去过那里并感到痛苦