My Type Visualiser Project

I've always like to be able to visualise software designs in diagram form. When looking at code its a constant struggle to filter out the detail and only take notice of the important stuff. Most of the time learning a new code base or refactoring code the details are not important immediately. I find just exploring the dependencies of a type and other types it consumes a good place to start understanding a class. Easier said than done.

Visualising a type and its dependencies and relationships to other types, is useful to me for two reasons:
1) Assessing what this subject type is doing, and is it well structured.
2) How difficult would it be to get the subject type under test.

Enter the Type Visualiser.

This tool is intended to target one .NET type and visualise its associations.  Different relationships are modelled as different coloured lines and arrow heads.  Line thickness indicates how often a type is consumed by the subject or how many different fields or properties use other types.  The style is loosely based on UML, but is by no means intended to strictly follow UML.

The tool targets compiled .NET libraries (and executables) and presents a list of types it can find inside the chosen library.

The tool is intended to give a strategic overview of a type and how it relates to other types, so members themselves are not shown.  Only statistics and totals are given to provide a sense of how big and complex a type is. Nearly everything has a tooltip to indicate the various symbols and lines.

I'm intending on adding a Testibility Index to indicate how "testable" a type is. The more strong relationships it has (to sealed or concrete classes as opposed to interfaces and abstracts) the higher the index. The more lines of IL code and members the higher the index.  I haven't really ironed out the details of how this feature will work yet.

If there's strong interest I might open source the project.

These diagrams help me assess how much time/effort is required to get an existing piece of code under test and refactor it as well as add new features.  Obviously the more complex the diagram the more this efforts any estimates I give.  For example, this monster class shown below is definitely a huge concern in terms of complexity and the number of strong types is "welded" to.

Clearly, this subject type is broken.

Some Resources on Patterns of Data Access with EF

Ayende's thoughts on Repository Pattern.

Prefer educating Developers rather than trying to protect (preventing) them from writing bad code.

Implementing a Repository Pattern in EF

(I'm not convinced by this article. It talks about separation from Data Access but it doesn't look unit testable to me. Check out the fields on the BLL class Repository, how would you mock/stub that?)

MSDN on Testability and EF

This definitely more interesting than the above article, but I still can see how the Intelligent Query Pattern gives much cleaner separation of concerns. Although, I'm only about 90% there. There's still a case (in my mind at least) to still allow simple linq queries direct against EF.

Walkthrough of Test Driven EF 4.0

Using Repository and Unit Of Work Patterns with EF4.0

Ayende on ORM's in general

A long read, but some complimentary points on EF and good insights into NHibernate.

An tiny lightweight alternative to EF PetaPoco (although it appears it relies on SQL strings - yuck).

Serialising a Linq Query to Json

IEnumerable<Employee> empJson = from emp in employees
                                where emp.Department == "IT Department"
                                select emp;
var ser = new DataContractJsonSerializer(typeof(IEnumerable<Employee>));
using (stream = new MemoryStream()) {
    ser.WriteObject(stream, empJson);
    string json = Encoding.Default.GetString(stream.ToArray());
    return json;

}