Saturday, June 28, 2008

Active Conventions with NDepend

Some time ago Patrick Smacchia wrote a nice article on his blog about active conventions on your code base. I thought I tried this for myself and made up some interesting CQL queries.

Suppose we want to enforce a BDD naming convention for every SetUp method. Such methods should be named Establish_context. The following CQL constraint reports those methods that are not named consistently:

// <Name> // NUnit SetUp methods that are not named consistently. // </Name> WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES "MyProject.Domain.UnitTests", "MyProject.Infrastructure.UnitTests" WHERE HasAttribute "NUnit.Framework.SetUpAttribute" AND !NameIs "Establish_context()"

Lets have another one. A while ago, I wrote this post about how WCF gave me this weird exception after I forgot to put a DataContract attribute on one of my DTO classes. Lets write another active convention for that:

// <Name>Data contracts without a DataContract attribute.</Name> WARN IF Count > 0 IN SELECT TYPES FROM NAMESPACES "MyProject.MyServiceContracts.DataContracts" WHERE !HasAttribute "System.Runtime.Serialization.DataContractAttribute"

Now here comes my personal favorite. Being the huge DDD adept that I am, I want to enforce that the domain is the core, the centerpiece, the kernel as you may of my application. I don't want it to have any dependencies to other assemblies in my application, especially not the infrastructure assembly.

// <Name>Domain is directly using the infrastructure</Name> WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES "MyProject.Domain" WHERE IsDirectlyUsing "ASSEMBLY:MyProject.Infrastructure"

It can't get any easier than this, now doesn't it? This is actively enforcing Separation of Concerns. Another way to have a convention about this is the following:

// <Name>Domain-Driven Design convention</Name> WARN IF Count > 0 IN SELECT ASSEMBLIES WHERE AssemblyLevel > 1 AND NameIs "MyProject.Domain"

This means that my domain assembly can only have a reference to the .NET framework assemblies and nothing else. This gets my geek heart pounding.

Imagine the possibilities if you incorporate this with your daily and continuous integration builds. Pure software quality assurance if you ask me.

Friday, June 27, 2008

The Entity Framework Team are Real Professionals

You have to hand it to these people: they sure have to put up with a lot of crap. I'm also guilty as charged for this. I already wrote about a lack of real-world usability and best practices in the past.

You probably heard about the ADO.NET Entity Framework Vote of No Confidence. The moment this went online, I signed it without any hesitation. I still believe that version 1.0 of the EF stinks badly compared to NHibernate. NHibernate allows me to write maintainable applications without sacrificing OO programming, and it will be far more superior for a long time to come. I agree that a first version of anything isn't feature complete, but it should support at least a couple of basic OO principles.

At first, I didn't want to blog about this until I read Chad's post. He mentions this blog post by Kathleen Dollard that made me scratch my head for a while. It's not the general insulting tone of the entire post that sets me off, but rather the following sentence somewhere in the middle of her post:

 EF is not a failure because it has a poor strategy for merging into source control

How on earth can you put something like this on your blog and still call yourself a professional developer? Source control is not negotiable.Period! If a tool doesn't allow me to use source control, then it's bye, bye baby! I thought we were past this by now? I guess not, so I will repeat this for the last time: you can't deliver maintainable software without proper source control in place!.

Regarding the data-driven approach vs the OO approach: those VB6 days are over! Wake up and smell the roses. I never witnessed an OO approach to fail in my eight years as a developer. Maybe I'm lucky. I don't know. What I do know is that a data-driven approach fails miserably every single time it's used in a software project of any size larger than an ant. Transaction scripts don't handle code duplication well, they violate separation of concerns and are a major disabler for loosely coupled (aka maintainable) applications.

Anyhow, back to the title of this post. The EF team has been very open about all this. Daniel Simmons announced the EF Advisory Council and the team responded in a real constructive way to the "Vote of No Confidence" by setting up this blog about the future design of the Entity Framework. These are some of the first positive signs that they are setting themselves up for success.

Saturday, June 14, 2008

Book review: NHibernate in Action

kuate_cover150 Writing this book review feels kind of weird  because it hasn't actually hit the shelves yet. It is accessible however through the Manning Early Access Program. This book provides a clear insight of using NHibernate as the data access layer of your applications and beyond.

The excessive amount of NHibernate features  isn't the only thing that is written down. There is also a good coverage of OO principles and Domain-Driven Design, although it isn't the primary objective of the book of course. This is especially true for the first and the last three chapters. If you've already read the nominal books DDD and you are familiar with Persistence Ignorance, then you can safely skim through these chapters unless you want to see the interpretation of the authors when it comes to these principles. If you are new to these concepts, then these chapters are of great value to wet your appetite.

Although this book covers a lot of ground, I would certainly recommend it when you're rather new to NHibernate and ORM's in general. I guess this still includes me, although I've been using NHibernate for quite some time now. If you already have some experience with NHibernate, then this book probably doesn't teach you that much. Still, it can quickly get you up to speed when you want to use a particular feature that you haven't used before.

The only minor thing about this book is that I'm afraid that it will soon be out-of-date. The book only covers NHibernate 1.2.x and no features from the upcoming 2.0 release, which adds a lot of new and interesting features. It would be nice if the book already covered some of these features as most of them are ported from Hibernate itself, which is the original Java version.

On the other hand, this book provides an in-depth view of the basic features of NHibernate, which aren't necessarily going to change that much over time anyway.

Let me round off this post by saying that I'm really impressed by the list of books that Manning is going to release the next couple of months. These are the ones that I'm particularly interested in:

I already bought LINQ in Action and also read a lot of good things about C# in Depth, which I'm going to pick up soon.

Take care.

Saturday, June 07, 2008


I just migrated my book shelf on 22 books and wish list to Shelfari. It seems that I'm way behind on my reading list.

Thursday, June 05, 2008

Annoying Bug in Visual Studio 2005

Today I hunted down a bug in Visual Studio 2005 that annoyed me tremendously for the past couple of weeks. Starting from this certain point in time, without any reason whatsoever (maybe a sun burst targeting my office desk or something), Visual Studio started littering my source tree with folders named Visual Studio 2005. In these directories there was another directory named Backup Files.

At first I thought that the configuration options for Visual Studio were wrong. I checked the directory settings for Environment/Import and Export Settings and Project and Solutions. Everything seemed in order.

After some journey through the Windows registry, I found this inconsistent value for the HKEY_CURRENT_USER\Software\Microsoft\Visual Studio\8.0\VisualStudioLocation key. It was set to the value "VisualStudioProject" to be more precise. Changing this value to the correct path in the Document and Settings directory solved he problem.

This is a very specific problem that really affected my mood. It even put these backup folders in places that didn't had any source file. Someone at Microsoft should get fired for this ;-) (no, just kidding). An IDE from JetBrains that targets .NET with Boo and IronRuby as first class citizens. That would be cool, don't you think?

Monday, June 02, 2008

NDepend - Static Analysis Made in Heaven

What is elegant code? Everyone agrees that this is a rather subjective topic. I wrote down my take on this matter not so long ago. Almost every developer out there (an probably myself included) thinks that their own code is the greatest thing since sliced bread and that code written by other developers is just, well ... old bread with hair on it.

Inheriting the code base of some legacy application that needs to be extended with a ton of new features which should have gone into production yesterday. Sure, we all have our war stories as developers. The first thing we usually do in a situation like this is reading the code. Then after some (short) time, we start complaining against our peers and managers how bad this code base really is. In fact, managers have grown a special skin against this kind of complaints coming from developers. This kind of complaints are not taken seriously by anyone just because it seems like such a subjective matter.

Actually, a good code base that is easy to maintain is not that subjective anymore. Object-oriented design has many principles, like the Single Responsibility Principle and Separation of Concerns among many others, that exactly describe how good code should look like. In order to prove to ourselves and our managers that we are writing good code an that the inherited legacy application is bad, we have to come up with some cold, hard facts. Besides code reviews, static analysis tools are the next best thing to verify the quality of our code. Such tools, integrated with daily builds and continuous integration, can help you and your team to figure out how well your project is doing. Note that these are just tools and that code reviews are still a lot better at the time of this writing.

We are using FxCop for number of years now and we are very pleased with it, although writing custom rules is rather cumbersome and has a high threshold to my feeling, probably because it is not that well documented. However, the rules that ship out-of-the-box are OK most of the time, so we keep using it.

I briefly looked at Microsoft Source Analysis last weekend, but I really didn't like it.

A couple of months ago, Patrick Smacchia provided me a review copy of NDepend. I gave it a try last week and it literally blew me away. This tool performs a complete X-ray on the code base of your project and provides an extended report with a huge amount of information about the quality and maintainability of your project.


Actually, I briefly reviewed this tool when it was in an early beta a couple of years ago. For some reason (probably stupidity on my behalf), I dismissed this tool entirely. What a mistake! Good that I finally come to my senses.


I thought I'd unleash this power to Pet Shop 4.0. After creating the project, I already got a huge HTML file that contained a lot of information. Here is an example of a chart that shows the Abstractness versus Instability.


The X-axis shows the instability, that indicates how easy it is for the public interface of an assembly to change incorporating the number of other assemblies depending on it. The Y-Axis indicates the abstractness, i.e. how easy it is to extend the types in an assembly without a recompilation.

Notice that the PetShop.Model assembly is in the Zone of Pain. This means that it is used by a lot of other assemblies and that it is hard to extend the types that it contains.  A couple of other assemblies are in the Zone of Uselessness, which means their types are very extensible but with few dependencies from other assemblies.

The report also contains a diagram that shows the dependencies between the different assemblies.


These diagrams are just a small part of the information that is contained by the report. When you close the report, you can use the NDependViewer application to further analyze the data.

NDepend Screenshot 1

Now we come to the part where NDepend really shines: CQL or the Code Query Language. NDepend treats the code of your application as a database. With CQL you can perform all sorts of queries on its code base. NDepend already provides a lot of  CQL queries out-of-the-box and also lets you write you own queries. It even has intellisense!

NDepend Screenshot 2

This gets my geek heart pounding. This means that there's a lot less friction involved when writing custom CQL queries as opposed to writing custom rules for FxCop. This particular CQL query returns the methods that have a Cyclomatic Complexity greater than 10, indicating that the OracleMembershipProvider needs some attention. When you double click one of the selected methods on the left, the code gets shown in Visual Studio. After a short inspection, it seems that the implementation of this class looks rather messy ("cough", understatement, "cough").

This is all just a tip of the iceberg. NDepend also lets you compare two different versions of your code base, performing CQL queries for determining the quality of the new code that was added. The latest version also supports test coverage metrics generated by NCover or Visual Studio. To make things even sweeter, NDepend ships with NAnt / MsBuild  tasks letting you generate this information as part of your daily builds / continuous integration.

With this tool, we as developers can come up with the hard facts. It allows you to dig right into the problem areas of a particular code base. There is even a CQL query that indicates which particular methods need refactoring.

NDepend Screenshot 3

The documentation of this tool is just great, the home page is filled with short demo movies and make sure to check out the metrics definitions and the quick reference.

You might suspect that I'm getting paid for this post, but actually, I'm not. This is just another great tool in my tool bag, not a silver bullet. The hardest part of starting out with this tool is the first 15 minutes. When you give it a fair chance and get past those 15 minutes, it will all be worth it. Just amazing work! My two thumbs up.

The Future of .NET

That's the title of the latest .NET Rocks episode. No big deal, just one of the better podcast episodes out there. Microsoft, are you listening? Maybe you should put your chairman on a stage on one of your next big developer conferences, screaming out maintainability, maintainability, maintainability! Let the ASP.NET MVC framework be your first big success and your guide on the path for providing us developers some tools and most important, some patterns & practices for creating more maintainable software.