19

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

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

我们争论过：我们应该有多少解决方案？

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

我很高兴听到每个方向（或其他方向）的优缺点和经验

4

12 回答 12

28

我从事过两种极端的产品：一种在单个解决方案中包含约 100 个项目，另一种包含超过 20 个解决方案，每个解决方案有 4-5 个项目（测试、业务层、API 等）。

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

单个解决方案在进行更改时非常有用——它更容易处理依赖关系，并允许重构工具正常工作。但是，它确实会导致更长的加载时间和更长的构建时间。

多种解决方案可以帮助实施关注点分离，并保持较低的构建/加载时间，并且可能非常适合拥有多个关注范围更窄且定义明确的服务边界的团队。然而，在重构方面，它们确实有一个很大的缺点，因为许多引用是文件引用，而不是项目引用。

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

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

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

于 2009-06-08T05:43:11.457 回答
18

解决方案确实适用于依赖管理，因此如果不止一件事依赖于它，您可以在多个解决方案中拥有项目。解决方案的数量实际上应该取决于您的依赖关系图。

编辑：这意味着您不应该将不相互依赖的项目粘贴到同一个解决方案中，因为它会产生依赖的错觉，这意味着当两个项目真正独立时，有人可以创建真正的依赖。

于 2009-02-09T21:07:10.137 回答
8

我已经研究了一个包含近 200 个项目的解决方案。如果您有足够的 RAM，这没什么大不了的 :)。

要记住的一件重要事情是项目相互依赖（无论是依赖项还是引用），它们可能应该在同一个解决方案中。否则，当不同的项目在不同的解决方案中有不同的依赖关系时，你会得到奇怪的行为。

于 2009-02-09T21:08:52.847 回答
4

您想要维护项目引用。如果您可以安全地将解决方案拆分为两个或多个相互依赖的离散项目集，那么就去做吧。如果你不能，那么他们都属于一起。

于 2009-02-09T21:06:50.200 回答
4

我们有一个包含大约 130 个项目的解决方案。大约 3 年前，当我们使用 vs.net 2003 时，这是一个可怕的问题。有时解决方案和 VSS 会崩溃。

但是现在有了 VS.NET 2005 就可以了。只有加载需要很多时间。我的一些同事正在卸载他们不使用的项目。这是加快速度的另一种选择。

将构建类型更改为发布是另一个问题。但是我们现在有 MSBuild 脚本。我们不再使用 VS.NET 的发布版本。

于 2009-02-09T21:11:41.110 回答
2

我认为你不应该夸大你的项目/解决方案的数量。组件化可以
和将被重用的东西，否则不要组件化！它只会使事情变得不那么透明并增加构建时间。也可以使用文件夹或使用逻辑类结构在项目中进行分区。

于 2009-02-09T21:06:05.867 回答
2

我正在使用一个目前有 405 个项目的解决方案。在非常快的机器上，这是可行的，但仅限于当前的 Visual Studio 2017 或 2012。其他版本经常崩溃。

于 2018-12-13T10:19:33.107 回答
2

在决定您需要多少项目和解决方案时，您需要考虑一些问题：

  • 应用程序的逻辑层；
  • 项目之间的依赖关系；
  • 项目是如何建造的；
  • 谁与什么项目合作；

目前我们有 70 个项目的 1 个解决方案。为了我们的持续集成，我们创建了 5 个 msbuild 项目，因此 CI 不会构建我们的开发解决方案。

以前，我们在单独的 git 存储库中有单独的表示（Web 和相关项目）层的解决方案。该解决方案被外包和自由 Web 开发人员使用。

于 2017-03-02T17:10:54.850 回答
1

我认为解决方案的实际数量并不重要。更重要的是你按照功能线分解事物。作为一个愚蠢的、人为的例子，如果你有一堆库可以处理与外部 Web 服务的互操作，那将是一个解决方案；一个带有它需要工作的 DLL 的 EXE 将是另一个。

于 2009-02-09T21:01:15.410 回答
1

一个解决方案中有这么多项目的唯一问题是引用和构建顺序开始变得混乱。

作为一般规则，我倾向于减少项目的数量（使项目更加通用）并让开发人员共享这些项目的源代码控制，但通过子命名空间将这些项目中的功能分开。

于 2009-02-09T21:07:10.887 回答
0

你应该有尽可能多的。没有硬性限制或最佳实践。练习并阅读什么是项目和解决方案，然后根据您的需求做出正确的工程决策。

于 2009-02-09T21:10:05.793 回答
0

在其他答案中已经说过，但是可能值得再说一次。

项目依赖关系很好，因为如果依赖关系发生变化，它们可以重建依赖项目。

如果您执行程序集文件依赖项，VS 或 MSBuild 将无法知道需要构建一串项目。将会发生的是，在第一次构建时，将重新构建已更改的项目。如果您已将依赖项放在构建输出上，那么至少在第二次构建时，依赖该项目的项目将构建。但是你有未知数量的构建需要到达链的末端。

使用项目依赖项，它将为您解决所有问题。

所以说有尽可能多（或少）的答案，以确保使用项目依赖项。

如果您的团队被分解为具有更正式发布机制而不是签入源代码的功能区域，那么将其拆分为这些行将是可行的方法，否则依赖关系图是您的朋友。

于 2009-02-09T21:39:56.017 回答