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

Question

当我产生一个依赖图时，我应该寻找什么东西？

，或者换一种说法，是有什么好看的图形VS坏的一个特点？

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

Answer 1

你可以发现的最大问题是绝对依赖周期。 NDepend工具提出了一个交互式dependency Matrix和一个dependency Graph，这将有助于发现dependency cyles。 声明：我的工具的开发者之一

注意，依赖矩阵是远远超过图表察觉周期调整。因为一个循环避免矩阵为三角形。

问题的其他范围是相对于你的应用程序结构：例如，它是正常的用户界面直接使用DB？或者更糟，数据库依赖于UI？

你可以写code rules over LINQ queries (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会议上的演讲者向我们展示了一些依赖关系图... 他指出的一个问题是寻找与您的代码库的不同功能部件之间的关系。这些可能会破坏封装。

而且我想看看每个部分的一般复杂..那些与行遍是犯罪嫌疑人。