One of the personal reasons that I had for co-founding Guild 3 was for me to re-discover my passion for software. I was suffering from something similar to what Davy Brion (quite bravely) outlined in Avoiding (Or Recovering From) Burnout. For me the age old adage of “a change is as good as a rest” has proven to be an extremely successful strategy.
One of the things that I had stopped doing was keeping an eye on various OSS projects to see what was on the horizon. Yesterday I (finally!) started to experiment with NHibernate 3.0. The first thing that caught my eye was QueryOver. As Fabio explained there are a lot of different ways of executing queries in NH. Certainly in the pre-LINQ days ICriteria was the predominantly recommended option because it has elements of type safety to it and its fluent-ish API broke everything down into small pieces and avoided string concatenation hell.
QueryOver is fluent a layer on top of ICriteria. It looks very LINQesque but it’s a very different animal, not least of all because there are some concepts in ICriteria that do not have a LINQ equivalent (caching etc.). In the short to medium term I suspect that it will become my de facto approach for NHibernate queries (I’ve used NHibernate LINQ and it’s great for simple queries but I’ve experienced significant issues with more complicated ones).
What I haven’t figured out yet is how, if at all, this will affect my data access testing strategy. Historically I’ve favored smoke tests that have really been doing little more than verifying that a given ICriteria query was semantically valid. Typically I only resorted to actually worrying about the results in specific cases (mainly due to the burden of maintaining test data for each possible scenario). Then again this sounds like a topic for another post doesn’t it…