.net - 包含数百个项目的解决方案是危险的还是笨拙的？

Question

我们的主要客户解决方案有 111 个项目。当我第一次加入这个团队时，我对我们有这么多项目感到惊讶(和震惊)，并建议将这些层级合并到更少但更大的组件中。我们的结构具有带有休眠映射文件的模型 (DTO)、带有数据 Controller 调用的 WCF 服务层、一些框架类型的项目以及带有多个模块的 winform CAB 应用程序。我们将使用单击一次部署。

由于构建时间(最坏情况下最多 15 分钟)，其他一些团队成员现在也很担心。我没有经验证据表明减少项目是个好主意，我想知道堆栈溢出社区是否有任何反馈。是否有令人信服的理由来改变我们的解决方案结构以整合项目？使用单击一次部署 100 多个程序集会遇到麻烦吗？加载和调用方法调用时，更多的程序集会导致缓慢吗？我们可能遇到的任何可能破坏事物的限制？

Answer 1

在一个解决方案中拥有多个项目(特别是当项目之间存在许多相互依赖关系时)的最大问题是编译时间会很快变慢。我已经看到当项目数量增长到如此大时，编译时间会达到几分钟到几十分钟。

如果需要加载和初始化 100 个程序集，应用程序启动也可能会受到影响。这当然假设应用程序需要所有 100 个程序集。

如此大量的项目也暗示了代码组织问题。我会称之为明确的代码气味。这看起来像是一种超出合理范围的解耦尝试——猜测有点建筑宇航员主义。

我不会担心部署故事，因为将一个程序集部署到一个目录与将 100 个程序集部署到一个目录没有太大区别……当然，通过 Web 部署 100 个程序集会更慢(100 个连接而不是 1 个，可能是有更大的尺寸......)。

有一些工具可以合并多个程序集，可以帮助解决这个问题 - 最著名的是来自 Microsoft - ILMerge .

在进行部署时要担心的更大问题是配置和正确配置，尤其是在大多数程序集需要自己的配置时。