dependencies - 在依赖图中容易发现哪些问题？

Question

当我生成依赖图时，我应该寻找什么？

或者换一种说法，好看的图和坏的图有什么特点？

编辑：这里的上下文是我第一次看我在 NDepend 中的程序集。

Answer 1

你能发现的最大问题肯定是依赖循环。NDepend 工具提出了一个交互式依赖矩阵和一个依赖图，这将有助于发现依赖循环。免责声明：我是该工具的开发人员之一

请注意，依赖矩阵比图更适合点循环。因为一个循环避免了矩阵是三角形的。

其他问题范围与您的应用程序结构有关：例如，UI 直接使用 DB 是否正常？或者更糟糕的是，数据库依赖于 UI？

您可以在 LINQ 查询 (CQLinq) 上编写代码规则来检查禁止的依赖项。以下代码规则检查 UI 类型不应直接使用 DB 类型：

// <Name>UI layer shouldn't use directly DB types</Name>
warnif count > 0

// UI layer is made of types in namespaces using a UI framework
let uiTypes = Application.Namespaces.UsingAny(Assemblies.WithNameIn("PresentationFramework", "System.Windows", "System.Windows.Forms", "System.Web")).ChildTypes()

// You can easily customize this line to define what are DB types.
let dbTypes = ThirdParty.Assemblies.WithNameIn("System.Data", "EntityFramework", "NHibernate").ChildTypes()
              // Ideally even DataSet and associated, usage should be forbidden from UI layer: 
              // http://stackoverflow.com/questions/1708690/is-list-better-than-dataset-for-ui-layer-in-asp-net
              .Except(ThirdParty.Types.WithNameIn("DataSet", "DataTable", "DataRow"))

from uiType in uiTypes.UsingAny(dbTypes)
let dbTypesUsed = dbTypes.Intersect(uiType.TypesUsed)
select new { uiType, dbTypesUsed }

Answer 2

什么的依赖图？上课？存储过程？

循环不好...

Answer 3

如果更改一个依赖项意味着您需要更改很多其他依赖项，那就不好了。
但是，是的，一些背景可能会有所帮助。

Answer 4

我不知道 NDepend 显示了什么，但倾向于进入代码的许多部分（特别是不相关的部分）的工件往往是坏的（恕我直言）。我认为这是“癌症代码”。

Answer 5

NFJS 会议上的一位演讲者向我们展示了一些依赖关系图......他指出的一种气味是寻找与代码库的不同功能部分有关系的东西。这些可能会破坏封装。

此外，我会查看每个部分的一般复杂性。那些满是线条的都是嫌疑人。