c# - 解决方案中的大多数项目

Question

对于 VS 2005，是否有最大数量的项目会导致性能问题。我们现在有多达 25 个项目并且还在不断增长。我们应该让这些二进制文件被引用还是我们将我们的应用程序逻辑分解成太多不同的项目。最近似乎开始成为一个大的性能问题。

score 5 · Accepted Answer

拥有过多的 DLL 文件可能会在运行时花费您，因此我建议您尽量减少项目数量。创建多个解决方案也是一种选择，但请尝试使解决方案彼此独立，这样您就不必在多个解决方案中调试和实现新功能 - 这可能很麻烦。

score 1 · Accepted Answer

是否存在贯穿所有 25 个项目的依赖链？如果某些项目不依赖于其他项目，请将它们放入自己的解决方案中。

如果您不需要并且通常不需要编译整个解决方案，请不要编译。通常您可以右键单击刚刚修改的项目并进行编译。VS 会找出需要重新编译哪些依赖项目。

除非您打算打断点，否则请使用“不调试就开始”。

某些 DLL 是否稳定且长时间未更改？它们也不必在您的解决方案中。

除非你真的必须，否则不要搜索整个解决方案。

真正的限制是人的思想。一个项目可以处理多少个文件？此外，除非您使用 ndepends 来跟踪依赖关系，否则在一个项目中放置多个类可能会导致过多的类依赖于其他类，从而使更改变得更加困难和风险更大。

score 1 · Accepted Answer

通常我们会尝试将解决方案中的项目数量保持在 10 以下。在 10 之后，您开始有缓慢的编译时间和缓慢的“项目重新加载”时间。

但这里的主要问题是为什么你有 26 个项目？一个简单的网站只能有一个项目，而数据层、业务层、表示层都在同一个项目中。

如果你只为这 3 层的东西拆分项目，我建议你修改这个。例如，我们在 3 层有 3 个项目。我们在单独的程序集中有 3 层的原因是我们正在执行其他软件以在项目后期使用数据层。将我们的业务层保持在主演示项目之外，使我们能够轻松地对我们的业务层进行单元测试，同时将无用的依赖项保持在演示者层之外。

因此，总的来说，将项目保持在 10 个以下，并查看是否可以将一些项目合并在一起。它既可以在编译时也可以在构建时节省您的时间。管理这些 DLL 也将更加容易。

score 0 · Accepted Answer

我会说它在构建时而不是运行时花费你。少即是快，但也许您并不总是构建所有这些。如果是这种情况，那么您应该减少金额。否则将它们分成不同的解决方案。然后只有构建服务器需要构建所有这些，并且每日构建需要整夜构建;-)

4 回答 4