问Visual Studio解决方案中建议的项目数

EN

我在两个极端的产品上都工作过:一个在单个解决方案中有大约100个项目，另一个有>20个解决方案，每个解决方案有4-5个项目(测试、业务层、API等)。

每种方法都有其优点和缺点。

单一的解决方案在进行更改时非常有用-它更容易处理依赖项，并允许重构工具很好地工作。然而，它确实会导致更长的加载时间和更长的构建时间。

多个解决方案可以帮助强制实施关注点分离，并保持较低的构建/加载时间，并且可能非常适合具有更窄焦点和定义良好的服务边界的多个团队。然而，当涉及到重构时，它们确实有一个很大的缺点，因为许多引用是文件引用，而不是项目引用。

也许在大多数情况下，混合方法可以使用较小的解决方案，但当需要进行更大规模的更改时，可以创建一个包含所有项目的单一解决方案。当然，你必须维护两个不同的解决方案...

最后，项目和依赖项的结构将对您组织解决方案的方式产生一些影响。

请记住，从长远来看，RAM比程序员的时间更便宜。

解决方案实际上是为了依赖管理而存在的，所以如果有多个东西依赖于它，那么你可以在多个解决方案中拥有项目。解决方案的数量实际上应该取决于您的依赖图。

编辑:这意味着你不应该将彼此不依赖的项目粘合到同一个解决方案中，因为这会造成依赖的错觉，这意味着当两个项目实际上应该是独立的时候，某人可能会创建一个真正的依赖。

我在一个有近200个项目的解决方案中工作过。如果你有足够的内存，这没什么大不了的:)。

需要记住的重要一点是，项目之间是相互依赖的(无论是依赖关系还是引用)，它们可能应该在同一个解决方案中。否则，当不同的项目在不同的解决方案中具有不同的依赖关系时，您会得到奇怪的行为。