Clever Geek Handbook

What problems are easy to spot in the dependency graph?

What things should I look for when creating a dependency graph?

Or, to put it another way, what are the characteristics of a good schedule and a bad one?

Edit: The context here is my first look at my assemblies in NDepend.

+1


source to share


5 answers


The biggest problem you can find is by far the Dependency Loops. The NDepend tool offers an interactive dependency matrix and dependency graph to help you identify dependent keels . Disclaimer: I am one of the developers of this tool

enter image description here

Note that the dependency matrix is ​​much more tailored than the graph for defining loops. Because the loop avoids the triangular matrix.



Other ranges of concerns relate to your application structure: for example, is it okay for the UI to use the DB directly? or much worse, does DB depend on the UI?

You can write code rules above LINQ queries (CQLinq) to check for forbidden dependencies. The following code rule verifies that UI types should not directly use DB types:

// <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 }
+1


source


dependence graph of what? classes? stored procedures?



cycles are bad ...

+1


source


If changing one dependency means you have many others to change, that's bad.
But yes, some context might help.

0


source


I don't know what NDepend is showing, but artifacts that tend to fall into many sections (not related sections in particular) of code will tend to be bad (IMHO). I thought of it as "Cancer Code".

0


source


A presenter at the NFJS conference showed us some dependency graphs ... One smell he pointed out was looking for things with relationships to different functional parts of your codebase. They are likely to destroy encapsulation.

Also, I would look at the overall difficulty of each section. Individuals with all lines are suspects.

0


source






More articles:


All Articles