Visual Studio解决方案中的建议项目数 [英] Recommended number of projects in Visual Studio Solution

问题描述

我们开始开发新的应用程序，其中将包括大约50个由MS Visual Studio中的C#开发人员开发的30-50个项目.

We are starting to develop new application that will include something like 30-50 projects developed by about dozen of developers with C# in MS Visual Studio.

我正在对应用程序模块进行组件化，以支持体系结构并启用并行工作.

I am working on componentize the application modules in order to support the architecture and enable parallel work.

我们争论:我们应该有几个解决方案?

We have argue: how many solutions should we have?

有人声称我们应该有1-2个解决方案，每个解决方案有15-30个项目.有人声称我们每个组件都需要一个解决方案，这意味着大约有10-12个解决方案，每个组件约有3-6个项目.

Some claim that we should have 1-2 solutions with 15-30 projects each. Some claim that we need a solution per component that means about 10-12 solutions with about 3-6 projects each.

我很高兴听到每个方向(或其他方向)的利弊，并对此进行体验

I would be happy to hear pros/cons and experience with each direction (or other direction thereof)

推荐答案

我在两种极端情况下都致力于产品开发:一个解决方案中有约100个项目，一个解决方案中有20个以上的解决方案，每个项目有4-5个项目(测试，业务层，API等).

I've worked on products on both extremes: one with ~100 projects in a single solution, and one with >20 solutions, of 4-5 projects each (Test, Business Layer, API, etc).

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

Each approach has its advantages and disadvantages.

进行更改时，单个解决方案非常有用-它更易于使用依赖项，并允许重构工具正常工作.但是，这样做确实会导致更长的加载时间和更长的构建时间.

A single solution is very useful when making changes - its easier to work with dependencies, and allows refactoring tools to work well. It does however, result in longer load times and longer build times.

多种解决方案可帮助实现关注点分离，并缩短构建/加载时间，并且可能非常适合于拥有多个重点更窄且服务边界明确的团队.但是，它们在重构方面确实存在很大的缺点，因为许多引用是文件引用，而不是项目引用.

Multiple solutions can help enforce separation of concerns, and keep build/load times low, and may be well suited to having multiple teams with narrower focus, and well defined service boundaries. They do however, have a large drawback when it comes to refactoring, since many references are file, not project references.

也许有一种混合方法的余地，在大多数情况下使用较小的解决方案，但在需要进行较大规模更改的时候创建一个包含所有项目的单一解决方案.当然，然后您必须维护两个单独的解决方案...

Maybe there's room for a hybrid approach use smaller solutions for the most part, but create a single including all projects for times when larger scale changes are required. Of course, you then have to maintain two separate solutions...

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

Finally, the structure of your projects and dependencies will have some influence on how you organize your solutions.

请记住，从长远来看，RAM比编程时间便宜...

And keep in mind, in the long run RAM is cheaper than programmer time...

这篇关于Visual Studio解决方案中的建议项目数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！