我在企业工作，我们在解决方案项目中使用多个项目，用于UI，业务逻辑和数据访问，数据库和另一个用于打印....但现在我在新的企业，经理告诉我我不必完成所有这个项目，只需要将它们放入解决方案中的一个项目中的单独目录中。
我只是想知道我是否必须说服他使用多个项目！
答案 0 :(得分：63)
我对接受的答案感到非常惊讶。我曾在两种环境中工作，并且发现多个项目总体上是有益的。实际的决定仍然取决于您的团队（如果单个项目没有阻止您实现目标那么就足够了。）
我依靠鲍勃叔叔Principles of OOD关于包裹管理。这些并不是众所周知（特别是与他的SOLID原则相比，他们的课堂设计），但它们是明智的。
取自鲍勃叔叔的OOD原则
前三个包装原则是关于包装内聚，它们 告诉我们在包装内放什么：
- REP释放重用等效性 原理重复使用的颗粒是释放的颗粒。
- CCP 通用闭包原则打包一起更改的类 一起。
- CRP使用的公共重用原则类 一起打包在一起。
最后三个原则是关于包之间的耦合， 并讨论评估a的包结构的指标 系统
- ADP非循环依赖原则。依赖图 包必须没有周期。
- SDP稳定的依赖关系 原则取决于稳定的方向。
- SAP The Stable 抽象原则抽象性随着稳定性而增加。
这符合我个人的经验，在这种经历中，倾向于减少项目经常导致我的经验出现问题：
较少的包可能导致差的依赖管理。单独的项目/程序集可以帮助保持内部/私人类和成员不被使用的地方
通常，在许多项目中，您开发了一套非常稳定且经过测试的“核心”库，这些库很少会发生变化。将这些组件保存在他们自己的项目中（甚至是解决方案）可以帮助他们避免更高层次的持续变化。
使用较少（或单个）项目产生的大型项目可能非常难以驾驭。 Visual Studio不会设置您的项目/解决方案镜像您的文件结构的期望，因此有组织的大型项目仍然可以作为驱动器上的混乱存在。
Visual Studio非常智能，可以避免重新编译没有更改的程序集。随着您的“核心”项目稳定，他们将看到更少的编辑，这可以节省编译时间。
与上述相同，使用较少的项目会导致始终重新编译代码 - 无论代码是否有相关更改。在一个非常大的项目中进行单行更改将导致完全重新编译。
当然，多个项目也有问题：
您必须对依赖项有所了解才能避免循环引用（.NET处理得相当好，但Visual Studio可以防止）
您的解决方案可能会变得足够大以保证子解决方案，这可能很难管理
解决方案的初始编译时间可能较慢
最后，.NET中一个很少使用的功能是单个.DLL可以包含多个模块（实际上它是几个共享一组元数据的程序集）。我不建议使用它，但知道它是如何工作的很有趣：http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge
答案 1 :(得分：49)
我实际上同意你的经理。
多个项目意味着多个程序集，大量复制程序集，以及通常较慢的编译时间。
如果您拥有多个项目的唯一理由是改进组织，那么您做错了。使用文件夹同样有效。
拥有不同程序集的一些正当理由是：
答案 2 :(得分：8)
我发现了一篇关于结构（项目或文件夹）在应用程序中的重要性的有趣文章。我会说，当你打开一个解决方案并看到一个项目列表时，这些名称会告诉我应用程序是如何构建的。等等
（MVP设计模式示例）
目录结构是您的代码的基础
“正如任何设计师都会告诉你的那样，这是设计的第一步 最重要的过程。前几招，创造了 形式，在其中传承其余的命运。“ - 克里斯托弗 亚历山大
（克里斯托弗亚历山大是一名建筑师。没有工作过 程序员，他影响了许多思考很多的人 节目。他的早期着作“模式语言”是原作 设计模式运动的灵感来源。他想了很长时间 如何建造美丽的东西很难，这些反思似乎 主要适用于软件构建。）
在CBC电台采访中，亚历山大讲述了以下故事 （在这里解释）：“我和我的一个学生一起工作。他是 在构建某些东西时非常困难。他只是不知道 如何进行。所以我和他坐在一起，我说：听着， 首先要弄清楚最重要的是什么。懂吗 直接先。在你的脑海里直截了当。慢慢来。别 太仓促想一想。当你觉得你有 发现它，当你心中毫无疑问它确实是 最重要的是，然后继续做最重要的事情 事情。当你做了最重要的事情时，问问自己是否 你可以让它更美丽。切断废话，直截了当 在你的脑海里，如果你能做得更好或没有。完成后，和 你觉得你不能做得更好，然后找到下一个 重要的是。“
应用程序中的第一个笔划是什么，它创建了它的整体 形成？它是目录结构。目录结构是 程序员在浏览源代码时遇到的第一件事 码。一切都从它流出。一切都取决于它。它是 显然是源代码最重要的一个方面。
考虑程序员遇到时的不同反应 不同的目录结构。对于逐个功能的样式， 应用程序员的想法可能是这样的：
“我明白了。这会一次性列出该应用的所有顶级功能。 很好。“”让我们看看。我想知道这个项目的位置......哦，在这里 是。我所需要的一切也就在这里，一切都在 同一个地方。非常好。“然而，对于逐层的风格， 应用程序员的想法可能更像是这样的： “这些目录什么也没告诉我。这个应用程序有多少功能？ 甘拜下风。它看起来与其他所有人完全一样。没有不同 一点都不大。我们再来一次......“”嗯。我想知道这个项目在哪里 位于....我猜它的各个部分都在应用程序上，四处传播 所有这些目录。我真的拥有我需要的所有物品吗？我猜 我们稍后会发现。“”我想知道这个命名约定是否仍然存在 被跟踪。如果没有，我将不得不在另一个中查找它 目录。“”哇，你看看这个单身的大小 目录...... sheesh。“其他域中的逐层包装无效
答案 3 :(得分：5)
由于顾虑分离。这将极大地帮助类/对象之间的意外引用。
对于WPF / Silverlight程序员，请考虑MVVM设计模式：将ViewModel和Views分成两个不同的项目将确保View对象没有引用到ViewModel中。
另一点是构建时间可能会缩短，因为每次都不会重新编译整个解决方案。对你的经理来说可能是一个很好的论据（但这个假设可能是错误的，具体取决于你的解决方案的规模）。
答案 4 :(得分：5)
如果您只 拥有一个应用程序，那么一个项目就可以了。但我认为这是非常罕见的。大多数情况下，您将拥有多个应用程序，因此通过拥有多个项目，您可以在应用程序之间重用组件，而无需执行共享源文件等hacky事项。
答案 5 :(得分：3)
如果需要，请使用不同的项目
您的解决方案的单独二进制文件，因此您可以灵活地进行补丁/更新准备和部署
管理插件的可能性
在C＃中使用C ++代码。
可重复使用的组件。程序集中声明的类型可以在公司的不同应用程序中重用，以提供统一的API。