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