.NET 解决方案 - 许多项目与一个项目答案

【问题标题】：.NET solution - many projects vs one project.NET 解决方案 - 许多项目与一个项目
【发布时间】：2009-11-06 21:23:39
【问题描述】：

我们目前拥有快速增长的 C# 代码库。目前我们有大约 10 个项目，分为常用类别、通用/实用程序、网络层、数据库、ui 组件/控件等。

我们偶尔会遇到循环依赖，其中项目 x 依赖于 y 中的某些内容，反之亦然。我们正在考虑将项目合并为一个，并仅使用结构文件夹/命名空间进行管理。我们有一个 Java 项目，当然它只使用文件夹/包来组织，所以我们不确定拥有多个项目会带来什么好处（如果有的话）。我们的项目都不需要特殊的项目属性，除了主运行项目，我们可以将其分开（并且非常精简）。

有没有人对为什么一个项目比多个项目更好/更差有任何经验，并且可以提出最佳方法？而且任何一种循环依赖的问题在这两种方法中都是有用的。

任何意见表示赞赏。

【问题讨论】：

在我看来，坦率地说，您需要一位建筑师。很少有人真正理解“什么属于哪里”和“为什么保持一致的架构很重要”。循环依赖 = 出了点问题。公共图书馆 = somone 放弃了。没有什么是常见的，如果你问我，那就是正确分离的反模式。

标签： c# .net visual-studio projects-and-solutions

【解决方案1】：

根据我的经验，如果您愿意，在多个项目中创建单个可执行文件的代码会很有用

在不同的部分使用不同的编程语言，
开发也被其他应用程序使用的库，或者
从概念上分离多个层（即，让 Visual Studio 确保没有从项目 Lib 到项目 App 的直接引用）。

就我个人而言，我的大部分决定都是基于第二点。我是否认为应用程序的这一部分可以是我在其他应用程序中可能需要的更通用的库？把它放在一个单独的项目中。否则，正如您所指出的，拥有一个项目通常会使开发更容易。

关于循环依赖：解决这个问题的推荐方法是将引用的东西的接口放到第三个项目中。例如，如果您有两个应用程序都通过远程处理共享某些对象，则将共享对象的接口放在库项目中，以确保它们对两个应用程序都可用。

如果不知道您的应用程序的确切设计，很难给出更具体的建议。

【讨论】：

感谢您的反馈。尤其是解决循环依赖的接口想法听起来像是解决我的问题的好方法。
赞成使用接口解决循环依赖的想法。
依赖注入

【解决方案2】：

如果您的项目具有循环依赖关系，则表明代码设计存在问题，而不是解决方案/项目模型存在问题。

【讨论】：

为什么有这么多赞成票。除了对提出真正问题的人说“你不知道自己在做什么”之外，这并没有真正的帮助。
这么多赞成，因为它是对的。类本身应该为其组件提供一个抽象层。如果两个类具有循环依赖关系，那么将这两个类放在单独的项目中就没有意义了。通常需要将两者都依赖的组件提取出来并放在自己的位置上。
System.Xml.dll和System.Configuration.dll之间也存在循环依赖
这不是恶意的。只是在这种情况下，似乎会出于错误的原因切换解决方案/产品结构。至于所有的赞成票，我不知道，这取决于社区。
关键是合并项目只是为了避免循环依赖影响构建系统，这是在隐藏你的问题，而不是解决它们。正确的解决方案是将代码重构为合理的非循环项目结构；从长远来看，这将始终提高可理解性、可测试性和可维护性。

【解决方案3】：

在项目之间建立依赖关系时，始终将一个视为“较低”而将另一个视为“较高”会有所帮助

较高级别的项目（例如 Web 界面）应该只依赖于较低级别的项目。较低的项目（例如实用程序）永远不应依赖于较高的项目，例如 Web 界面。如果发生这种情况，要么意味着您的较高级别的项目确实应该在较低的项目中，反之亦然。

【讨论】：

【解决方案4】：

一般来说，在这些情况下，拥有多个 VS 项目（在一个 VS 解决方案中）确实有意义

您可以在另一个项目（类库）中重用生成的 DLL
您希望在分层架构中分离事物，您可以在其中删除 DAO dll 并与另一个进行交换
只是不同的前端项目（即 ASP.net MVC 应用程序）需要部署在不同的物理位置，但使用相同的 BL、DAL。

如果你说你有循环依赖的问题，那么你的代码设计就有问题。可能您可以将多个项目使用的逻辑放在一个类库中，该类库旨在在许多项目中重用。

一般来说，如果你真的不需要它，我会说你不应该添加更多的项目。拆分成项目意味着增加更多的复杂性，所以当你这样做时，你应该从中获得合理的好处。

【讨论】：

【解决方案5】：

我们注意到，随着项目数量的增加，Visual Studio 的性能会显着下降。对于包含十几个 C# 项目的解决方案，从“调试”配置切换到“发布”配置这样简单的操作可能需要 15 秒以上的时间。

此外，与 Reed 关于构建时间的评论相反，我看到构建时间在增加，因为 Visual Studio 似乎在项目开销上花费了大量时间。实际的编译时间似乎很快，但从构建到能够运行的总时间很长。

我的建议是将项目数量保持在您可以逃脱的最低限度。如果您有充分的理由需要多个项目，请根据需要使用它们，但更愿意将它们放在一起。如有必要，您还可以重构以将项目一分为二。

【讨论】：

构建时间的有趣点。虽然不是非常重要，但等待构建确实会在最关键的时候拖延开发，当我处于最佳状态时:)所以知道这一点很有用谢谢。

【解决方案6】：

将解决方案分成不同的项目（以及程序集）有几个原因，主要归结为可重用性y和职责分离。

现在您的目标应该是使程序集（也称为项目）对您的解决方案中的其他程序集具有最少的依赖关系，否则您还不如在更少的程序集中拥有所有内容。例如，如果您的 UI 组件对您的数据访问代码有很强的依赖性，那么可能有问题。

真的，这归结为针对通用接口进行编程。

注意：

当我说“否则你也可以在更少的程序集中拥有所有东西”时，我并不一定是在暗示这是错误的做法。为了实现真正的关注点分离，您将编写更多代码并且必须更多地考虑您的设计。所有这些额外的工作可能对你没有多大好处，所以请仔细考虑。

【讨论】：

您可以通过一个项目和适当的文件夹结构实现可重用性和职责分离，这就是所有其他框架的工作方式。每个额外的组装只会增加更多的维护工作（大多数时候是不必要的）。

【解决方案7】：

多个项目允许在多个应用程序中更好地重用特定类型。它还可以缩短构建时间，因为不需要为所有代码更改重新构建某些项目。

单个项目让生活更轻松，因为您不必担心依赖关系。只要意识到轻松是有代价的——它也让糟糕的设计决策更容易潜入代码库。循环依赖，无论是在一个项目还是多个项目中，通常都是设计缺陷，而不是要求。

【讨论】：

【解决方案8】：

您可能会发现以下 Martin 文章值得一看：Design Principles and Design Patterns (PDF)(Java)。

C# 的修订版本专门在 C# 中的敏捷原则、模式和实践 中提供。

两者都表达了不同的指导方针，可以帮助您确定哪些内容属于哪里。然而，正如所指出的那样，循环依赖表明设计存在问题，或者组件中的某些内容属于不同的组件。

【讨论】：

这与敏捷无关。

【解决方案9】：

在我工作的地方，我们选择了一种方法，其目标是每个解决方案都有一个项目。所有代码库项目也都有一个测试工具应用程序和/或一个单元测试应用程序。

只要代码库通过测试，发布版本（当然还有 Xml 文档文件）就会转移到“Live”文件夹中。

任何需要这些其他项目功能的项目都必须从“Live”文件夹中引用它们。

优势非常明显。任何项目总是访问已知的工作代码。从来没有机会引用正在进行的程序集。每个程序集都会对代码进行测试，从而更容易理解错误的来源。较小的解决方案更易于管理。

希望这会有所帮助！

鲥鱼

【讨论】：

考虑为此使用版本控制系统。

【解决方案10】：

从单个项目开始。将代码库拆分为更多项目的唯一好处就是缩短构建时间。

当我真正想从主项目中分离出一些可重用的功能时，我将为它启动全新的解决方案。

【讨论】：

-1 虽然你说的是真的，但这并不是全部。
我发现解决方案中的项目概念没有用，将各个层放入单独的文件夹中同样适用于我和数百万快乐地使用其他编程语言的其他人。