我们的主要客户解决方案有111个项目。当我第一次开始这个团队时，我很惊讶（并且惊慌失措）我们有这么多项目，并建议将这些层级合并到更少但更大的组件中。我们的结构具有带有nhibernate映射文件的模型（DTO），带有数据控制器调用的WCF服务层，一些框架类型项目以及具有多个模块的winform CAB应用程序。我们将使用点击一次部署。
由于构建时间（最差情况下最多15分钟），其他一些团队成员现在也担心。我没有经验证据表明较少的项目是一个好主意，并且想知道堆栈溢出社区是否有任何反馈。是否有令人信服的理由改变我们的解决方案结构来整合项目？我们会遇到使用click-once部署100多个程序集的麻烦吗？加载和调用方法调用时，更多的程序集会导致缓慢吗？我们可能遇到的任何限制可能会破坏事情吗？
答案 0 :(得分：8)
在单个解决方案中包含许多项目的最大问题（特别是当项目之间存在许多相互依赖关系时）是编译时间会快速减慢。我看到，当项目数量增长时，编译时间会持续几分钟到几十分钟。
如果需要加载和初始化100个程序集，应用程序启动也会受到影响。当然，这假定应用程序需要所有100个程序集。
如此众多的项目也暗示了代码组织的问题。我会称这是一种明确的代码味道。它看起来像是一种超越合理的脱钩尝试 - 一种建筑宇航员的想法。
我不担心部署故事，因为将一个程序集部署到一个目录与将100部署到一个目录没有太大区别......当然，通过Web部署100个程序集会更慢（100个连接而不是1个，可能有更大的尺寸......）。
有些工具可以合并多个程序集，可以帮助解决这个问题 - 最着名的是来自Microsoft - ILMerge。
在进行部署时需要担心的一个更大的问题是配置并使其正确，特别是如果大多数程序集需要自己的配置。
答案 1 :(得分：2)
选择创建110个项目的人所寻求的好处有可能在一个.dll中实现110个名称空间。
当依赖关系开始蠕变时，大量的dll会更明显（1 dll引用其他22个），但对于命名空间也是如此（如果你没有使用using语句，那么就会产生挫折引用许多其他命名空间。
此外，当您合并程序集时，您将失去“内部”，并且可能希望使某些方法不像它们那样可见，这无论如何都是好事。
答案 2 :(得分：1)
一旦编译完成，我认为不会有任何问题。
话虽如此，仅凭个人经验，我知道很多项目可能会影响你的效率。在我的（中等功率）机器上，在解决方案中有许多项目，只需加载visual studio就需要很长时间。此外，当编译你的工作流程需要将近四分之一个小时时，集中力将被打破（如果你决定在等待的时候做其他事情，那就更是如此）。
答案 3 :(得分：1)
In a gist: 部署将是至少您的后顾之忧。
除了较长的编译时间，您将面临的实际问题是：＆gt;＆gt;可能的构建效率低下并降低了开发人员的工作效率。
根据您所拥有的自动构建设置的类型...在相同项目中的一组独立解决方案中的失败以及在开发人员的基础上频繁签入...必然会给您（如果还没有）一系列构建失败的噩梦。
以下是您可以采取的措施：
根据依赖程度，您可以收集最少依赖的项目。例如，如果项目A具有最少量的代码流失...它可以通过自动程序集引用分离出来...取决于您正在使用的构建解决方案。
此外，一个简单的提示，Devs可以加载他们正在工作的项目，以便更快更有效地启动。
如果您有多环境部署设置，例如：DEV，UAT，STAGE，MIRROR和PROD ..每次正确转换配置也会带来巨大痛苦。因此，您可以将所有非平凡的配置移动到数据库级别......并保留更清晰的配置文件......仅将它们用于绝对必要的实体。