什么是更好的，许多小型组件，或一个大型组件？

Question

所有都在标题中：）

目前，我们有一个VS2005解决方案，包含20多个项目。像

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。因此，我们必须小心不要创建一些。

Answer 1

我曾经在几家公司工作，其中有太多项目在各方面都很痛苦。我还没有去过任何少数项目的地方，尽管这当然是可能的。

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

我喜欢将不同的层（表示，业务逻辑，数据访问）分开，并且很高兴拥有一个与产品无关的通用实用程序库，但在很多情况下都是如此。

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

Answer 2

一个装配的优点：

• 潜在性能
• 可能更容易部署

许多组件的优点：

• 其他所有。假设这些是良好的内聚模块，它有助于分离关注点，通过强制您考虑对架构进行调平/分层等来控制依赖关系。

Answer 3

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

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

Answer 4

编译时间。如果您将项目分成几部分，则只需编译已修改的部分。如果它是一个大项目的全部内容，那么每次更改内容时都必须重新编译所有内容。根据你的项目有多大，这可能是一个大问题。

Answer 5

首先，如果你有大量的项目，Visual Studio开始花费更长的时间来加载你的解决方案，而不是很少有代码的项目。

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