多个项目和一个解决方案的好处是什么?

我对这个公认的答案感到非常惊讶。我在这两种环境下都工作过，发现多个项目总体上是有益的。实际的决定仍然取决于你的团队(如果一个项目不妨碍你实现目标，那么它就足够了)。

关于包管理，我依靠Bob大叔的OOD原则。这些不是很为人所知(特别是与他的SOLID类设计原则相比)，但它们是明智的。

引自Uncle Bob's Principles of OOD

前三个包原则是关于包内聚的告诉我们在包里放些什么:

• REP发布重用等效性原则复用的颗粒就是释放的颗粒。
• 中国共产党共同闭包原则一起更改的类被打包在一起。
• CRP通用重用原则所使用的类一起包装在一起。

最后三个原则是关于包之间的耦合，然后讨论评估a的包结构的指标系统。

• ADP无循环依赖原理的依赖图包必须没有循环。
• SDP稳定依赖原理依赖于稳定的方向。
• SAP马厩抽象性随稳定性的增加而增加。

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

• 更少的包可能导致依赖管理不佳。单独的项目/程序集可以帮助防止内部/私有类和成员在不应该使用的地方使用

• 通常对于许多项目，您开发的是非常稳定且经过测试的"核心"库集，这些库很少更改。将这些组件保留在它们自己的项目(甚至解决方案)中可以帮助它们与高层中正在进行的更改隔离。

• 使用更少(或单个)项目导致的大型项目可能非常难以控制。Visual Studio没有设置项目/解决方案镜像文件结构的期望，因此一个有组织的大型项目仍然可以在您的驱动器上混乱地存在。

• Visual Studio足够聪明，可以避免重新编译没有更改的程序集。随着你的"核心"项目的稳定，他们将看到更少的编译，这可以节省编译时间。

• 与上面一样，使用更少的项目导致总是重新编译代码-无论它是否有相关的更改。

在一个非常大的项目中，一行更改将导致完全重新编译。

当然，多个项目也可能有自己的问题:

• 你必须意识到你的依赖关系，以避免循环引用(这是。net处理得相当好，但Visual Studio工作来防止)

• 您的解决方案可能变得足够大，以保证子解决方案，这可能是棘手的管理

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

最后，. net中很少使用的一个特性是，一个。dll可以包含多个模块(实际上是几个程序集共享一组元数据)。我不建议使用这个，但是知道它是如何工作的很有趣:http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge

我实际上同意你的经理。

多个项目意味着多个程序集，大量的程序集复制，通常会减慢编译时间。

如果你有多个项目的唯一理由是改善组织，那么你做错了。使用文件夹也同样有效。

使用不同程序集的正当理由如下:

• 你有一个插件架构
• 您需要单独部署程序集
• 你需要用多种语言工作
• 你正在创建在不同地方使用的库

我发现了一篇关于应用程序中结构(无论是项目还是文件夹)的重要性的有趣文章。我要说的是，当您打开一个解决方案并看到一个项目列表时，其中的名称给了我一个如何构建应用程序的指示。等

(MVP设计模式示例)

1. BLL(业务)
2. DAL(持久化(映射、约定等))
3. Web
4. PL(表示层)
5. 测试(当然测试需要在一个单独的项目中)

目录结构是你代码的基础

"任何设计师都会告诉你，这是设计的第一步最重要的过程。最初的几笔，创造了形体，承载着其他人的命运。"——克里斯多夫亚历山大

Christopher Alexander是一名建筑师。没有做过程序员，他影响了很多思考很多问题的人编程。他早期的著作《模式语言》就是原版设计模式运动的灵感。他想了很久关于如何建造美丽的东西，这些反思似乎在很大程度上也适用于软件构建。)

在CBC电台采访中，Alexander讲述了下面的故事(此处转述):"我和我的一个学生一起工作。他是建造东西很困难。他只是不知道怎么继续。所以我和他坐在一起，我说:听着，首先要弄清楚什么是最重要的。得到直接放在第一位。把这句话记在心里。慢慢来。不太草率了。考虑一下。当你觉得你已经发现它的时候，在你心中毫无疑问，它确实是那个最重要的事情，然后把它变成最重要的事情事情当你做了一件最重要的事情时，问问自己你可以让它更漂亮。废话少说，把事情搞清楚在你的脑海里，你是否能让它变得更好。当这一切都完成了，然后如果你觉得自己不能做得更好，那就去找下一个重要的事情。"

应用程序的第一个笔画是什么，它创建了整个应用程序形式?它是目录结构。目录结构为这是程序员在浏览源代码时遇到的第一件事代码。一切都从它而来。一切都取决于它。它是显然，这是源代码中最重要的方面之一。

考虑程序员遇到时的不同反应不同的目录结构。对于按功能打包的样式应用程序程序员的想法可能是这样的:

"我明白了。这将一次性列出应用程序的所有顶级功能。好了。"让我们看看。我想知道这个项目位于....哦，在这里是多少。我需要的其他东西也都在这里了还是那个地方。太好了。"然而，对于按层打包的样式，应用程序程序员的想法可能更像这样:"这些目录什么也没告诉我。这个应用程序有多少功能?难倒我了。它看起来和其他的一模一样。没有区别在所有。太好了。又来了……"嗯。我想知道这件东西在哪里位于……我猜它的各个部分遍布整个应用程序，散布在所有这些目录。我真的有所有我需要的东西吗?我猜我们稍后会知道。"我想知道这种命名惯例是否仍然存在被跟踪。如果没有，我就得在另一本里查一下目录"。"哇，你看看这首单曲的大小目录…天哪。"在其他域中按层打包是无效的

来源

如果您只有曾经有一个应用程序，那么一个项目是好的。但我认为这种情况非常罕见。大多数情况下，您将拥有多个应用程序，因此通过拥有多个项目，您可以在应用程序之间重用组件，而无需执行诸如共享源文件之类的低级操作。

因为关注点的分离。这将极大地帮助类/对象之间的意外引用。

对于WPF/Silverlight程序员，考虑MVVM设计模式:将ViewModels和Views分离为两个不同的项目将确保View对象没有引用到ViewModel。

另一点是构建时间可以更短，因为整个解决方案不需要每次都重新编译。对于你的经理来说，这可能是一个很好的理由(但这个假设可能是错误的，这取决于你的解决方案的大小)。

如果需要，请使用不同的项目

• 为您的解决方案分离二进制文件，因此您可以灵活地准备和部署补丁/更新

• 管理插件的可能性

• 在c#中使用c++代码

• 可重用组件的使用。在程序集中声明的类型可以在公司的不同应用程序中重用，以提供统一的API。