我们正在开始开发新的应用程序，其中包括大约 12 名开发人员在 MS Visual Studio 中使用 C# 开发的 30-50 个项目。
我正在致力于应用程序模块的组件化，以支持架构并实现并行工作。
我们争论：我们应该有多少种解决方案？
有人声称我们应该有 1-2 个解决方案，每个解决方案包含 15-30 个项目。有人声称我们每个组件都需要一个解决方案，这意味着大约 10-12 个解决方案，每个解决方案大约有 3-6 个项目。
我很高兴听到每个方向（或其他方向）的优点/缺点和经验
我开发过两种极端的产品：一种在单个解决方案中包含约 100 个项目，另一种包含超过 20 个解决方案，每个解决方案包含 4-5 个项目（测试、业务层、API 等）。
每种方法都有其优点和缺点。
进行更改时，单一解决方案非常有用 - 它更容易处理依赖项，并且允许重构工具正常工作。然而，它确实会导致更长的加载时间和更长的构建时间。
多个解决方案可以帮助强制实施关注点分离，并保持较短的构建/加载时间，并且可能非常适合多个团队的关注范围更窄和定义明确的服务边界。然而，在重构方面它们确实有一个很大的缺点，因为许多引用是文件而不是项目引用。
也许混合方法有空间，在大多数情况下使用较小的解决方案，但在需要更大规模更改时创建一个包含所有项目的单一解决方案。当然，您必须维护两个单独的解决方案......
最后，项目和依赖项的结构将对您组织解决方案的方式产生一些影响。
请记住，从长远来看，RAM 比程序员的时间更便宜......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
