Friday, April 27, 2007

.NET Domain-Driven Design with C#: Problem-Design-Solution

A while ago I blogged about Domain-Driven Design and how I like it so much. I mentioned that Tim McCarthy is writing a book that I'm pretty much looking forward to. Today he announced a new project on CodePlex for the source code of his upcoming book called .NET Domain-Driven Design with C#: Problem-Design-Solution. In order to wet your appetite, you can check out the slides and code of his talk about Domain-Driven Design using the ADO.NET Entity Framework. I recommend that you have a look.

The presentation starts out touching some of the key concepts and patterns of DDD. The second half explains what the ADO.NET Entity Framework means to DDD. In my humble opinion, the ADO.NET Entity Framework, in its current state, cannot be used in DDD scenarios. His impressions are indeed the same as mine:

Great Hope for the future, but Pain for the present

Indeed, my favorite O/R-mapper today is still NHibernate, although I'm still digesting its large and massive amount of features. Actually, I'm done with low level ADO.NET altogether. If you're not yet convinced that the ADO.NET Entity Framework in its current form is a bad idea, then give this a read. I'm still hoping for the best though, hopefully in a not too distant future.   

Thursday, April 26, 2007

SD WORX is hiring!

SD WORX organizes a job event on the 14th and 15th of May 2007. They've invited some really funny guys to help persuade you to come work for SD WORX. If you want to join our team, we have two job openings for you (the job descriptions are in Dutch):

Maybe we'll hear from you?

Friday, April 13, 2007

NUnit 2.4 constraints

The forthcoming release of NUnit 2.4 supports a constraint-based syntax for assertions. Don't worry, the old syntax (classic model) is still going to be available for a long time to come (they even did some further enhancements). If you have used Rhino Mocks for mocking interfaces and classes in your unit tests, then you should be already familiar with a constraint-based design.

The following unit test shows a simple example:

[Test] public void Add_TwoIntegers_CheckResult() { Int32 result = Calculator.Add(96, 4); Assert.That(result, Is.EqualTo(100)); }

The classic "Hello Pluto" example just to illustrate the clean syntax and fluent interface of the new assertion model. You can also make use of a few constraint modifiers:

[Test] public void Add_TwoDoubles_CheckResult() { Double result = Calculator.Add(96.0, 4.0); Assert.That(result, Is.EqualTo(100.0).Within(0.0002)); }

It's even possible to combine constraints:

[Test] public void GetSomething_CheckNotNullAndNotEmpty() { String result = Subject.GetSomeString(); Assert.That(result, Is.Not.Null & Is.Not.Empty); }

Man, don't you just love this syntax! It's almost unnecessary to mention that NUnit 2.4 delivers a whole lot of constraint classes out-of-the-box. But now comes the fun part. What's really interesting is that it's very easy to write your own custom constraints. Every constraint derives from the Constraint base class which in turn implements IConstraint.

In order to try something out, I've created a constraint class like the CollectionEquivalentConstraint but for DataTables instead of collections. Those of you who know me are scratching their heads after reading this last sentence. My dislike of the DataSet, DataTable and their related classes is widely known but this would bring us off-topic. I thought it would make a nice example. Here goes ...

I derived a class from NUnit.Framework.Constraints.Constraint and created an override for the Matches method:

public override Boolean Matches(Object actual) { base.actual = actual; DataTable actualDataTable = actual as DataTable; Boolean result = (null != actualDataTable); result &= IsSubsetOf(actualDataTable, _expected); result &= IsSubsetOf(_expected, actualDataTable); return result; }

The IsSubsetOf method determines whether the first specified DataTable (subset) is a subset of the second specified DataTable (superset):

private Boolean IsSubsetOf(DataTable subset, DataTable superset) { // Check if the number of columns are different if(subset.Columns.Count != superset.Columns.Count) { return false; } // Check if the specified superset contains the // DataColumns of the specified subset and if // they support the same data type. foreach(DataColumn dataColumn in subset.Columns) { Int32 dataColumnIndexInSuperset = superset.Columns.IndexOf(dataColumn.ColumnName); if(-1 == dataColumnIndexInSuperset) { return false; } if(dataColumn.DataType != subset.Columns[dataColumnIndexInSuperset].DataType) { return false; } } // Check if the data rows of the specified subset // are contained by the specified superset. foreach(DataRow dataRow in subset.Rows) { if(!IsDataRowInDataTable(dataRow, superset)) { return false; } } return true; }

Notice that the IsSubsetOf method is private. If I wanted to create a DataTableSubsetConstraint class (like CollectionSubsetConstraint) I could move the IsSubsetOf method into a base class.

This way it's possible to write your own constraints that you can use for your own unit tests. You can start exploring the constraints model in NUnit by using the greatest documentation tool ever build: Reflector.

Update 23/04/2007:

You can download the source code here. Note that this code is just for trying out some of the new features of NUnit 2.4 and should only be used as an example.

Sunday, April 08, 2007

Build a solid core

Essential reading from Jean-Paul S. Boodhoo about building a solid core. This post contains a number of truths that I want to point out.

Many developers need to spend more time focusing on their core skill-set, as opposed to chasing after the current “hot technology of the month”

When I started out as a programmer, almost every book or article I've read was about technology (mostly related to C++ and later on .NET). The books and articles that I've read over the last year are mostly about core skill-sets: 

I've read the last two books for the third time already. The books that I'm planning to read this year are:

just to name a few. Keeping in touch with the "technology du jour" (I'm now reading the excellent Programming WCF Services) is also important, but not as important as the core skills. It's just that learning about Object-Oriented Programming, Domain-Driven Design and Test-Driven Development, Design Patterns, ... etc. are skills and techniques that you can keep using for many years to come. 

When asked the question “Do you know how to program in Objects?”, the answer is almost always a resounding yes. After a bit of careful examination it often becomes evident that lots of people (not just in the MS world) are writing procedural code masquerading as objects.

I must admit, I've done this too before I took a dive into Domain-Driven Design. I think this is used a lot in the .NET community, especially because Microsoft promotes it this way. The resulting code is hard to maintain and business logic is scattered all over the place.

My admiration goes to people like Karl Seguin and his Code Wiki, trying to create awareness and do something about it. Through the use-case of a Wiki, he shows how to create simple, maintainable, object-oriented software. Actually, the source code of the Code Wiki can be explored through the Wiki itself (how is that for eating your own dog food). If you want to become a better programmer, take a look at the source code and read the first two chapters of his book on The Code Wiki.

You can read as much books as you want without getting your feet wet, it's useless. Trying things out for yourself is fundamental in becoming a great programmer. Instead of reading books and articles, have a look at other people's code. Checkout the source code of your favorite open-source project and dive right in.

Wandering through the source of the Code Wiki, I found a class named SafeDataReader. It's a DbNull-aware DataReader. Why didn't I think of that? Well, I think I'm going to start using it right away.