我对解决方案加载时间和构建时间特别感兴趣——更少的解决方案是否意味着更好的性能？
请注意，我指的不是构建应用程序的性能。
处理较少数量的项目时，加载时间和构建时间是否更有效？
作为指导，我们的 Visual Studio 解决方案中有 50-60 个项目。
ripper234
问问题
4283 次
10 回答
13
（我对解决方案加载时间和构建时间特别感兴趣——更少的解决方案是否意味着更好的性能？）
这是Patrick Smacchia 的相关主题，描述了拥有少量程序集（此后是少量项目）的好处。他准确地谈到了装配数量如何影响构建时间和其他因素。
我鼓励你阅读 Patrick 的博客。他有很多关于代码组件化的文章。
根据我个人的经验，拥有几十个项目的解决方案是很痛苦的。IMO 拥有超过 10 个项目将导致明显的维护问题并影响您的生产力。
于 2009-01-18T09:50:58.577 回答
4
我取决于你的项目，大部分时间我使用 10-15。项目越少，构建时间就越短。
我通常有的项目是：
- 具有异常和错误处理的基础项目
- 商业逻辑
- 数据访问层 - 存储库
- WebForms 或 WinForms 或 WPF UI
其中一些我会分成 3-4 个其他项目。我也会有 NUnit 测试项目。
于 2009-01-18T09:35:42.927 回答
3
50-60对我来说听起来很多。我发现有很多项目，打开 Visual Studio 可能需要很长时间。如果您更改许多其他项目所依赖的项目，构建时间可能会很糟糕，但我不知道 10 个项目（每个项目有 20 个类）和 100 个项目（每个项目有 2 个项目）之间有什么不同。（换句话说，我不确定构建中每个项目的开销。）即使你不更改任何东西，大概每个项目都必须检测它是否需要重建任何东西——我无法想象那是免费，但如果不使用您自己的代码进行尝试，就很难给出更明确的信息。
我曾在多家公司工作过，他们有很多项目，每个项目只有几个课程——这些课程可以很容易地合并到一个项目中。根据我的经验，这也具有维护/可管理性的好处。（当然，不要心甘情愿地这样做——要明智。）
如果您实际上有合理规模的项目，只是其中很多，请考虑在可能的情况下拆分解决方案。如果它们都是小型项目，请考虑合并其中的一些。如果您无论如何都没有发现自己在等待 Visual Studio（打开/构建），那么不要太担心。
于 2009-01-18T09:32:18.317 回答
3
在您的解决方案中包含太多项目是一个坏主意。它会影响构建时间。请参阅这篇文章，该文章将构建时间与几种构建工具进行了比较。根据文章，Visual Studio 每个项目需要 2 秒，即使该项目不是构建的一部分。
这也符合我的经验，Visual Studio 是可用的最慢的构建工具之一。在 Visual Studio 6 和 2006 之间，对于一个相对简单的 C 项目，我的构建时间从 1 分钟变为 5 分钟。
于 2009-01-18T09:46:24.857 回答
3
聚会迟到了，但到目前为止，没有一个答案提到构建配置。您的解决方案中可以有很多项目，而无需在每次运行时都构建它们。单击 Debug/Release 组合并创建一个新的构建配置 - 在那里您可以决定要构建或不构建哪些项目。
为什么要这样做？我这样做是为了让我可以随意“转到定义”，这样我就可以快速地将项目进出我的构建，而无需经历所有添加项目的痛苦。
另外，请注意，如果您有解决方案文件夹，您可以右键单击并在该文件夹上构建，这将构建该文件夹中的所有项目。
于 2009-08-20T13:15:23.713 回答
1
当您创建很多小项目时，我看到的问题是：
1/封装：要在两个项目之间共享的类、方法或属性必须是公共的，因此在任何地方都可见。你拥有的项目越多，你就越有可能泄露一些秘密......
2/程序集总数：正如Aku所写，更少的项目意味着更少的程序集。由于每个项目都在本地复制他们使用的程序集，因此您的文件夹中最多可以有 (n * (n - 1)) / 2 个程序集（程序集 1 的 49 个副本、程序集 2 的 48 个副本，...）。对于 50 个项目，这是1176个文件！=> 好吧，你可能少了很多（200？），但仍然足以让一两个过时的副本在这里和那里......
于 2009-01-18T10:36:32.650 回答
1
我在一个有大量项目的项目上工作，在 50-60 的范围内，我发现与开发人员懒惰/健忘相关的问题相比，较长的加载时间是可以接受的。
许多项目依赖于基础库，因此在基础库更改时需要重新构建。由于项目在任何给定时间都可能发生变化，因此让开发人员只处理一个子集意味着如果他们懒惰，当从 CM 工具接收到更新时，他们将不会重建整个应用程序。然后，他们可以花费大量时间来尝试修复问题，从而了解为什么会出现问题。如果 VS 知道整个依赖关系树，那么这一切都解决了，并且快速构建所有内容可以使其全部正常工作。
我意识到一个优秀的开发人员会知道这一点并默认这样做，但不是每个人都很棒，有时甚至伟大的人也会休息。
于 2009-01-18T12:41:25.330 回答
1
于 2009-07-17T12:21:04.853 回答
0
在我看来，这只是个人组织和秩序的问题。如果您希望在同一个解决方案下有很多以某种方式相互连接的项目，您可以这样做。我认为你只需要考虑你是否真的需要它们。每个解决方案没有神奇的最大项目数
于 2009-01-18T09:28:51.647 回答
0
我尝试坚持的一般做法是每个解决方案 4-5 个项目。
- 商业逻辑
- 通信层（服务器相关）
- 用户界面
- 测试项目以利用/测试其他三个项目
这通常符合我们的风格以及我们如何实施它。如有必要，我们也可以在其中包含其他内容，但这些实例对我们来说并不像这四个一样常见。
于 2009-07-17T13:06:16.567 回答