Tuesday, March 25, 2008

Strongly typed NHibernate Criteria with C# 3

I, like many others, hate string literals. Of course, I mean string literals that have some meaning to the code itself, not the "hello, world" kind of strings. They are not type-safe, not easy to refactor, etc. The drawbacks have been mentioned a lot.

In particular, it always bothered me that NHibernate suffers from this problem, specially in the Criteria API. Well, now with C# 3 AST manipulation we can easily fix this. I wrote a simple set of helper classes and extension methods that provide an Expression parameter wherever there was a string parameter describing a property name. Let's see an example:

Instead of writing this:

IList cats = sess.CreateCriteria(typeof(Cat))
    .Add( Expression.Like("Name", "F%")
    .AddOrder( Order.Asc("Name") )
    .AddOrder( Order.Desc("Age") )

You can write this:

IList cats = sess.CreateCriteria(typeof(Cat))
    .Add( ExpressionEx.Like((Cat c) => c.Name, "F%")
    .AddOrder( OrderEx.Asc((Cat c) => c.Name) )
    .AddOrder( OrderEx.Desc((Cat c) => c.Age) )

which is a bit longer, but refactorable.

Code is here (NHibernate 1.2)

UPDATE 2/21/2009: Dan Miser has kindly submitted a patch to port these extensions to NHibernate 2.0.1GA. Code is here. Thanks Dan!

UPDATE 3/28/2010: Two years have passed now since I originally published this and several similar solutions have popped up. In particular, I recommend NH Lambda extensions for NHibernate 2.x which seems to be more complete, less verbose, and better maintained than my own solution. NHibernate 3 will have a new official API similar to this, named QueryOver. If you're stuck with NHibernate 1.2 the only solution available is the one presented in this article.

Related projects:

Sunday, March 16, 2008

Injectable file adapters

Someone must have done this, but I really couldn't find it. I'm talking about an IoC-friendly System.IO.File replacement. You know, unit tests shouldn't touch the file system, etc. So if your code writes a file and want to unit-test it, you pretty much have to mock the writing of the file. Except there's a known problem, System.IO.File is a static class, and those are not mockable. Even TypeMock can't mock System.IO.File since it's part of mscorlib. So the only solution left is to build an interface and a wrapper around File. So, here's the source, probably the most boring code I've ever written. I've also included a static locator that gets the IFile implementation using Ayende's IoC static accessor to the Windsor Container, so you can write code like this:

public void Copy() {
    var mocks = new MockRepository();
    var container = mocks.CreateMock<IWindsorContainer>();
    var fileImpl = mocks.CreateMock<IFile>();
    With.Mocks(mocks).Expecting(delegate {
        Expect.Call(() => fileImpl.Copy(null, null))
    }).Verify(delegate {
        FileEx.Copy("source", "dest");                

So you only have to replace your calls to System.IO.File to FileEx and that's it. You get the benefits of testability and extensibility (yes, sometimes you need to provide a different behavior for File.WriteAllText()) and you don't have to deal with interfaces, implementations, etc once you have set up the container. Personally, I prefer to make explicit the dependency for IFile in my components.

Like I said, I was very surprised that I couldn't find a working implementation of this... specially because there was a big debate a year ago about maintenability, YAGNI, dependency injection, coupling and more, and Anders NorĂ¥s commented this solution on one of his own posts.

Well, I hope someone finds this useful.

Friday, March 14, 2008

ReSharper 4 helps learning C# 3 syntax

So, ReSharper 4 nightlies have been available for download for around a month now, and I've been using it successfully at work with VS2008 from the first published build. Exceptions are uncommon and when they happen nothing really breaks, i.e. your code won't get messed up. Progress from one build to the next is amazing, lots of bugs get fixed and it just gets better and better. I won't get into the specific new features since that's been covered a lot.

IMO, the best feature is that it actually speeds up your learning of C# 3 features. When I first started coding in VS2008, my code came out naturally in C# 2 style, something like:

Dictionary<string, string> dict = new Dictionary<string, string>();
dict["one"] = "1";
dict["two"] = "2";

Although i did know about the C# 3 features, I had to consciously make an effort to use them. It's like making an expression jump from your receptive to your productive vocabulary. You know the words, but they just won't come out!

But I'm a CTRL+ALT+F (code reformat) junkie, and you add some alt-enter magic and you get:

var dict = new Dictionary<string, string> {
    {"one", "1"},
    {"two", "2"},

And after a while of constantly reading your own code automatically converted to C# 3 by ReSharper, you gradually get used to it and it just starts coming out like that naturally. Now it's part of your "productive vocabulary"!

So don't be afraid of the nightly status and give ReSharper 4 a try!