通过在 Visual Studio 中创建 依赖项关系图 ，在高级别描述应用的体系结构。 使用依赖项关系图验证代码，确保代码与此设计保持一致。 还可以在生成过程中包括层验证。
若要查看 Visual Studio 哪些版本支持此功能，请参阅 版本对体系结构和建模工具的支持。
注释
从 Visual Studio 2019 版本 16.2 开始，支持 .NET Core 项目的依赖项关系图。
什么是依赖项关系图？
与传统的体系结构关系图一样，依赖项关系图标识设计的主要组件或功能单元及其相互依赖性。 关系图上的每个节点称为 层，表示命名空间、项目或其他项目的逻辑组。 可以绘制设计中应存在的依赖项。 与传统的体系结构关系图不同，可以验证源代码中的实际依赖项是否符合指定的预期依赖项。 通过在 Team Foundation Server 上对常规生成进行验证，可以确保程序代码通过将来的更改继续遵守系统的体系结构。 请参阅 依赖项关系图：参考。
如何使用依赖项关系图设计或更新应用
以下步骤概述了如何在开发过程中使用依赖项关系图。 本主题后面的部分将详细介绍每个步骤。 如果要开发新设计，请省略引用现有代码的步骤。
注释
这些步骤按近似顺序显示。 你可能希望重叠这些任务，对任务重新排序以适应自己的情况，并在项目中每次迭代开始时重新访问它们。
为整个应用程序或其中的层创建依赖项关系图。
定义层以表示应用程序的主要功能区域或组件 。 根据这些层的函数命名这些层，例如“Presentation”或“Services”。 如果有 Visual Studio 解决方案，可以将每个层与 项目集合（如项目、命名空间、文件等）相关联。
发现层之间的现有依赖关系。
编辑层和依赖项 ，以显示希望代码反映的更新设计。
通过创建层来表示主体体系结构块或组件并定义依赖项，以显示每个层如何使用其他层来设计应用程序的新区域。
编辑图表的布局和外观 ，以帮助你与同事讨论。
根据依赖项关系图验证代码 ，以突出显示代码与所需体系结构之间的冲突。
更新代码以符合新体系结构。 在验证不显示冲突之前，以迭代方式开发和重构代码。
在生成过程中包括层验证 ，以确保代码继续遵守你的设计。
创建依赖项关系图
必须在建模项目中创建依赖项关系图。 可以将新的依赖项关系图添加到现有建模项目、为依赖项关系图创建新的建模项目，或复制同一建模项目中的现有依赖项关系图。
重要
不要将现有依赖项关系图从建模项目添加到另一个建模项目或解决方案中的其他位置。 以这种方式复制的依赖项关系图将具有与原始关系图相同的引用，即使修改关系图也是如此。 这将阻止层验证正常工作，并可能导致其他问题，例如尝试打开关系图时缺少元素或其他错误。
请参阅 从代码创建依赖项关系图。
定义层以表示功能区域或组件
层表示 项目的逻辑组，例如项目、代码文件、命名空间、类和方法。 可以从 Visual C# 和 Visual Basic 项目中的项目创建层，也可以通过链接文档（如 Word 文件或 PowerPoint 演示文稿）将规范或计划附加到层。 每个层在关系图上显示为一个矩形，并显示链接到它的项目数。 层可以包含描述更具体的任务的嵌套层。
作为一般准则，根据其函数命名层，例如“Presentation”或“Services”。 如果项目紧密相互依赖，请将它们放置在同一层中。 如果这些构件可以单独更新或在单独的应用程序中使用，请将其置于不同的层中。
小窍门
某些类型的工件可以链接到层，但不支持对依赖项图进行验证。 若要查看项目是否支持验证，请打开 层资源管理器 来检查项目链接的 “支持验证 ”属性。 请参阅 发现层之间的现有依赖关系。
更新不熟悉的应用程序时，还可以创建代码映射。 这些关系图有助于在浏览代码时发现模式和依赖项。 使用解决方案资源管理器浏览命名空间和类，这些命名空间和类通常与现有层非常对应。 通过将这些代码构件从解决方案资源管理器拖动到依赖项关系图，将其分配给层。 然后，可以使用依赖项关系图来帮助你更新代码并使其与设计保持一致。
请参阅：
发现层之间的现有依赖关系
只要与一个层关联的项目具有对与另一层关联的项目的引用，就存在依赖项。 例如，一个层中的类声明一个变量，该变量在另一层中具有类。 可以通过反向工程来发现现有依赖项。
注释
某些类型的工件无法对依赖项进行反向工程。 例如，不会对从或到链接到文本文件的层的依赖关系进行反向工程。 若要查看哪些项目具有可反向工程的依赖项，请右键单击一个或多个层，然后单击“ 查看链接”。 在 层资源管理器中，检查 “支持验证 ”列。 对于此列显示 False 的项目，不会对依赖项进行反向工程。
在层之间进行依赖项的反向工程
选择一层或多个层，右键单击所选层，然后单击“ 生成依赖项”。
通常，你将看到一些不应存在的依赖项。 可以编辑这些依赖项，使其与预期设计保持一致。
编辑层和依赖项以显示预期设计
若要描述你计划对系统或预期体系结构所做的更改，请使用以下步骤编辑依赖项关系图。 还可以考虑进行一些重构更改，以在扩展代码之前改进代码的结构。 请参阅 改进代码的结构。
| 至 | 执行这些步骤 |
|---|---|
| 删除不应存在的依赖项 | 单击依赖项，然后按 DELETE。 |
| 更改或限制依赖项的方向 | 设置 其 Direction 属性。 |
| 创建新的依赖项 | 使用 依赖关系 和 双向依赖项 工具。 若要绘制多个依赖项，请双击该工具。 完成后，单击 “指针 ”工具或按 ESC 键。 |
| 指定与某一层关联的工件不能依赖于指定的命名空间 | 在层的 “禁止命名空间依赖项 ”属性中键入命名空间。 使用分号 （;） 分隔命名空间。 |
| 指定与层关联的项目不得属于指定的命名空间 | 在层的 “禁止命名空间” 属性中键入命名空间。 使用分号 （;） 分隔命名空间。 |
| 指定与层关联的项目必须属于指定命名空间之一 | 在层的 必需命名空间 属性中键入命名空间。 使用分号 （;） 分隔命名空间。 |
改进代码的结构
重构更改是不影响应用程序行为的改进，但有助于使代码在将来更易于更改和扩展。 结构良好的代码具有易于抽象到依赖项关系图的设计。
例如，如果在代码中为每个命名空间创建一个层，然后对依赖项进行反向工程，则层之间应有一组最小的单向依赖关系。 如果使用类或方法作为层创建更详细的关系图，则结果还应具有相同的特征。
如果情况并非如此，代码将更难以在整个生命周期内更改，并且不太适合使用依赖项关系图进行验证。
设计应用程序的新区域
开始开发新项目或新项目中的新区域时，可以绘制层和依赖项，以帮助在开始开发代码之前识别主要组件。
如果可能，请在依赖项关系图中显示可识别的体系结构模式。 例如，描述桌面应用程序的依赖项关系图可能包括演示文稿、域逻辑和数据存储等层。 涵盖应用程序中单个功能的依赖项关系图可能具有模型、视图和控制器等层。
为每个层（ 如命名空间、类或组件）创建代码项目。 这样，可以更轻松地理解代码，并将代码工件链接到层。 创建每个项目后，立即将其链接到相应的层。
不必将大多数类和其他项目链接到层 ，因为它们属于较大的项目，例如已链接到层的命名空间。
为新功能创建新关系图。 通常，将有一个或多个依赖项关系图来描述整个应用程序。 如果要在应用程序中设计新功能，请不要添加或更改现有关系图。 相反，请创建自己的关系图来反映代码的新部分。 新关系图中的层可能包括新功能的呈现层、域逻辑层和数据库层。
生成应用程序时，代码将针对整体关系图和更详细的功能图进行验证。
编辑演示文稿和讨论的布局
为了帮助你识别层和依赖项或与团队成员讨论它们，请通过以下方式编辑图表的外观和布局：
更改图层的大小、形状和位置。
更改层和依赖项的颜色。
- 选择一个或多个层或依赖项，右键单击，然后单击“ 属性”。 在 “属性” 窗口中，编辑 Color 属性。
根据关系图验证代码
编辑关系图后，可以随时或每次构建时根据代码进行手动验证。
请参阅：
更新代码以符合新体系结构
通常，首次针对更新的依赖项关系图验证代码时，将显示错误。 这些错误可能有多种原因：
工件被分配到不正确的层。 在这种情况下，移动工件。
一个构件（例如类）以与架构相冲突的方式使用另一个类。 在这种情况下，重构代码以删除依赖项。
若要解决这些错误，请更新代码，直到验证期间不再出现错误。 这通常是一个迭代过程。 有关这些错误的详细信息，请参阅 使用依赖项关系图验证代码。
注释
开发或重构代码时，您可能会有新的构件需要链接到依赖关系图。 但是，例如，如果具有表示现有命名空间的层，并且新代码只会向这些命名空间添加更多材料，则可能不需要这样做。
在开发过程中，你可能希望在验证期间抑制某些报告的冲突。 例如，你可能想要抑制已处理或与你的具体情境无关的错误。 在忽略一个错误时，最好在 Team Foundation 中记录一个工作项。 若要执行此任务，请参阅 使用依赖项关系图验证代码。
在生成过程中包括层验证
若要确保代码中未来的更改符合依赖项关系图，请包括对解决方案的标准生成过程进行层验证。 每当其他团队成员生成解决方案时，代码中的依赖项与依赖项关系图之间的任何差异都将报告为生成错误。 有关在生成过程中包括层验证的详细信息，请参阅 使用依赖项关系图验证代码。