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

Question

当我在企业工作时，我们在解决方案中使用了多个项目-用于UI、业务逻辑、数据访问、数据库和打印的项目。现在我在一个新的企业中，经理告诉我，我不必制作所有这些项目，但我必须将它们放在解决方案中的一个项目中的单独目录中。

我只想知道我是否必须说服他使用多个项目！

Answer 1

我真的同意你们经理的意见。

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

如果你拥有多个项目的唯一原因是改进了组织，那么你就做错了。使用文件夹也同样有效。

具有不同程序集的一些合理原因是：

• 您有一个插件architecture
• You需要单独部署程序集
• 您需要使用多种语言
• 您正在创建要在不同位置使用的库

Answer 2

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

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

摘自鲍勃大叔的面向对象设计原则

前三个包原则是关于包内聚的，它们告诉我们应该在包中放什么：

• 代表发布重用等价原则，重用的颗粒就是发布的颗粒。
• CCP共同更改的公共闭包原则类被打包在一起。
• CRP将一起使用的通用重用原则类打包在一起。

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

，

• ，ADP，非循环依赖原理包的依赖图不能有圈。

，

• ，SDP，稳定依赖原理依赖于稳定的方向。
• SAP稳定的抽象原则抽象性随着稳定性的增加而增加。

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

• 较少的包可能导致较差的依赖项管理。单独的项目/程序集可以帮助防止内部/私有类和成员在不应该被
• 的地方使用。通常情况下，对于许多项目，你会开发一组非常稳定和经过测试的“核心”库，这些库很少改变。将这些组件保存在它们自己的项目(甚至是解决方案)中，可以帮助它们与高层的持续更改隔离开来。
• 由于使用较少(或单个)项目而导致的大型项目可能非常难以控制。Visual Studio不会期望您的项目/解决方案反映您的文件结构，因此一个有组织的大型项目仍然可以存在，因为您的drive.
• Visual Studio上的混乱足够聪明，可以避免重新编译没有更改的程序集。随着你的“核心”项目稳定下来，他们将看到更少的编译，这可以节省时间compiling.
• Likewise以上，使用更少的项目导致总是重新编译代码-无论它是否有相关的变化。在一个非常大的项目中，一行更改将导致完整的recompilation.

当然，多个项目也会有它们的问题：

为了避免循环引用，你必须意识到你的依赖项(

• .NET处理得很好，但是
• 的解决方案可能变得足够大，以保证子解决方案，这可能是棘手的manage
• Initial编译时间一个解决方案可能是较慢的

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

Answer 3

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

(MVP设计模式示例)

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

目录结构是代码的基础

“正如任何一位设计师都会告诉你的那样，设计过程中最重要的是第一步。创造形式的最初几个步骤，决定了其余的命运。”--克里斯托弗·亚历山大

(Christopher Alexander是一位建筑师。在没有做过程序员的情况下，他影响了许多对编程有很多想法的人。他的早期著作“模式语言”是设计模式运动的原始灵感。他对如何构建漂亮的东西进行了长期而艰苦的思考，这些思考似乎在很大程度上也适用于软件构建。)

在CBC的一次电台采访中，Alexander讲述了下面的故事(在这里转述)：“我和我的一个学生一起工作。他在建造一些东西时遇到了很大的困难。他就是根本不知道该怎么做。所以我和他坐在一起，我说:听着，从找出最重要的事情开始。先弄清楚这一点。把这一点记在心上。不用着急。别太着急。想一想吧。当你觉得你已经找到了它，当你的脑海中没有怀疑它确实是最重要的事情时，那么就去做最重要的事情。当你做了最重要的事情时，问问自己，你是否可以让它变得更美。少说废话，只要把它想清楚，如果你能让它变得更好的话。当这一切完成后，你觉得你不能让它变得更好，然后找到下一个最重要的事情。

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

考虑程序员在遇到不同的目录结构时的不同反应。对于功能包风格，应用程序程序员的想法可能是这样的：

“我明白了。这一次列出了这款应用的所有顶级功能。很好。”“让我看看。我想知道这个东西located....Oh在哪里，在这里。我需要的其他东西也都在这里，都在同一个地方。太好了。”然而，对于逐层打包的风格，应用程序程序员的想法可能更像这样：“这些目录什么都不能告诉我。这个应用程序中有多少功能?我搞不懂。它看起来和所有其他应用程序完全一样。完全没有区别。太好了。我们又来了……”“嗯。我想知道这个项目在哪里……我猜它的各个部分都在应用程序中，分布在所有这些目录中。我真的有我需要的所有项目吗?我想我们稍后就会知道了。”“我想知道这个命名约定是否还在遵循。如果不是，我将不得不在另一个目录中查找它。”“哇，你能看看这个directory...sheesh有多大吗？”在其他域中逐层打包是无效的

Source