c# - 多个项目和一个解决方案有什么好处？

Question

<分区>

Answer 1

我对接受的答案感到非常惊讶。我在这两种环境中都工作过，并且发现多个项目总体上是有益的。实际决定仍取决于您的团队(如果单个项目不会阻止您实现目标，那么这就足够了)。

我靠着鲍勃大叔的Principles of OOD关于包管理。这些不是很出名(尤其是与他的类设计 SOLID 原则相比)，但它们是明智的。

取自 Uncle Bob 的 OOD 原理

The first three package principles are about package cohesion, they tell us what to put inside packages:

• REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
• CCP The Common Closure Principle Classes that change together are packaged together.
• CRP The Common Reuse Principle Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

• ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
• SDP The Stable Dependencies Principle Depend in the direction of stability.
• SAP The Stable Abstractions Principle Abstractness increases with stability.

这些符合我的个人经验，在我的经验中，倾向于较少的项目经常会导致问题:

• 较少的包会导致依赖性管理不佳。单独的项目/程序集有助于防止内部/私有(private)类和成员在不应使用的地方使用

• 通常在许多项目中，您会开发一组非常稳定且经过测试的“核心”库，这些库很少更改。将这些组件保留在它们自己的项目(甚至解决方案)中有助于将它们与更高级别的持续变化隔离开来。

• 由于使用较少(或单个)项目而产生的大型项目可能非常难以控制。 Visual Studio 不会期望您的项目/解决方案反射(reflect)您的文件结构，因此一个有组织的大型项目仍然可以在您的驱动器上以困惑的形式存在。

• Visual Studio 足够智能，可以避免重新编译没有任何更改的程序集。随着您的“核心”项目稳定下来，它们将看到更少的编译，这可以节省编译时间。

• 与上述类似，使用较少的项目会导致总是重新编译代码——无论它是否有相关更改。一个非常大的项目中的一行更改将导致完全重新编译。

当然多个项目也可能有它们的问题:

• 您必须认真对待您的依赖关系以避免循环引用(.NET 处理得相当好，但 Visual Studio 可以防止)

• 您的解决方案可能会变得足够大以保证子解决方案，这可能很难管理

• 解决方案的初始编译时间可能较慢

最后，.NET 中一个很少使用的功能是单个 .DLL 可以包含多个模块(实际上它是几个程序集共享一组元数据)。我不建议使用它，但了解它的工作原理很有趣:http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge