Random Code

I’ve just about finished migrating a bunch of code from using LINQ based queries against my IRepository, which follows this approach discussed by Fabio Maulo, to enhanced query objects, which follow this pattern; again from the formidable mind of Fabio Maulo.

As I was writing the queries, I realised that I was effectively encapsulating the query logic into a self contained object, which is not unlike what a stored procedure does.  So here I am, 10 years or so after I started encapsulating my queries in stored procedures and some 2 or 3 years after giving up stored procedures, encapsulating my queries again.

But why the change?

While LINQ queries work well in small simple cases, you rapidly come to understand that it is effectively the lowest common denominator for working with your ORM (I prefer NHibernate but it applies as well to most others).  The workaround for this is to use a bunch of extension methods meaning you end up referencing your ORM from your service layer which (rightly or wrongly) makes me feel ill.  Enhanced Query Objects allow you to leverage the native power of your ORM while proving a suitably minimalistic interface which greatly increases SoC and simplifies testing of the query consumers.  The implementation also allows the queries to be thoroughly tested in isolation without too much difficulty.