当我生成依赖图时,我应该寻找什么?
或者换一种说法,好看的图和坏的图有什么特点?
编辑:这里的上下文是我第一次看我在 NDepend 中的程序集。
当我生成依赖图时,我应该寻找什么?
或者换一种说法,好看的图和坏的图有什么特点?
编辑:这里的上下文是我第一次看我在 NDepend 中的程序集。
你能发现的最大问题肯定是依赖循环。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 }
什么的依赖图?上课?存储过程?
循环不好...
如果更改一个依赖项意味着您需要更改很多其他依赖项,那就不好了。
但是,是的,一些背景可能会有所帮助。
我不知道 NDepend 显示了什么,但倾向于进入代码的许多部分(特别是不相关的部分)的工件往往是坏的(恕我直言)。我认为这是“癌症代码”。
NFJS 会议上的一位演讲者向我们展示了一些依赖关系图......他指出的一种气味是寻找与代码库的不同功能部分有关系的东西。这些可能会破坏封装。
此外,我会查看每个部分的一般复杂性。那些满是线条的都是嫌疑人。