The Specification pattern using LinqSpecs

In my previous post about the Specification pattern I showed how the pattern works and how to implement it. I’ve also uploaded a sample project on Specification to GitHub. But my implementation suffers from a serious fallback: you cannot generate database queries using it, instead you have to pull everything into memory and iterate over that. Luckily you haven’t have to write and parse your own expression trees (although it could be a nice experience). There’s a nice library on CodePlex called LinqSpecs which does just that. Disclaimer: I have nothing to do with LinqSpecs and didn’t take part of its development. I just found it extremely useful so I thought I’d share it in my blog.

The LinqSpecs implementation is a little bit different than what I wrote. First it uses an abstract base class instead of an interface. Then it doesn’t use methods to concatenate the various specifications, instead it relies on overloading the logical operators. But the most important thing is that it doesn’t return a simple Boolean value whether or not your candidate satisfies the specification. It returns an expression instead. The method looks like as follows:

For me it was a bit unclear how to work with this, but here’s a concrete implementation:

And here’s how to use it in an arbitrary repository:

Since the specification returns an expression you don’t have to provide one in the Where extension method on the datacontext, so the syntax feels more right. One issue arises with unit testing, since testing the previous version was much more intuitive. I wouldn’t like to copy a discussion here, instead here’s a link from the project page on unit testing specifications.

The Specification Pattern

A recurring problem in my job is designing composite search forms. I guess it’s a fairly common scenario to receive a specification of a massive form with tons of checkboxes, textboxes and other UI controls for filtering your model. I knew there has to be a good way to do this, and I found the specification pattern which does just that.

Imagine your average repository :

It’s a barely testable, tightly coupled something which behaviour you cannot easily modify. It’s our starting point. We’ll have something like this when we finish:

The main concept of the pattern is to abstract away each search criteria into its dedicated class. The resulting classes then can be unit-testable, easily modifiable and even reusable. Reusability came very handy in my last project where I built a class for each search criteria then I just composed them in various ways to satisfy the business need.

The core of the specification pattern is an interface or an abstract class, depending on your personal taste, which looks like this:

This does nothing particular, just a generic interface with a single bool method taking a parameter of the type you want to filter. This is the absolute minimum you need to start working.

But the power of the pattern is that you can combine your classes with bool logic. A common choice is to have a base CompostieSpecification class, but if you have an abstract Specification class you can combine the two. CompositeSpecification looks like this in my example project:

Notice that it has three methods, And, Or and Not which returns concrete specification subclasses. Here’s how the AndSpecification class looks like, I’m pretty sure you’ll get the idea of the other two after this:

This was the abstract part of our implementation. You can find all of the above in my accompanying GitHub Specification sample project. They come fully covered with unit tests, too.

Now let’s look at our concrete person example. The sample project loads a bunch of randomly created person objects and lets you filter them by name, age and job title. Here’s the PersonNameSpecification implementation which is responsible for filtering by name:

The significant gain is that now you can unit test this search filter. I included a bunch of tests (the specifications themselves fully covered) so you can check out them.

In my sample project the creation of the specifications is the job of the SpecificationBuilder class, and it does a less than stellar job, and complicate things unnecessarily so I wouldn’t recommend that as a valuable example. This code fragment focuses on the pattern much better:

Specification is suited for otherwise complicated filtering, and typically a database is involved. In this case you’d prefer to use the IQueryable interface instead of IEnumerable and let your ORM build an optimal query instead of pulling everything into memory and filtering there. My sample isn’t suited for that, you’ll need additional work. You’ll need to build an expression tree from your specifications. Fortunately there’s a nice project on CodePlex called LinqSpecs which just does that. In my next post I’ll show you how to modify this example to work with it.

The Model-View-Presenter pattern

My job is to develop custom SharePoint solutions (mostly web parts with various business functionality). Since SharePoint doesn’t support ASP.NET MVC I need to work with WebForms. It’s a decent technology, but after working with MVC for years it’s a serious fallback. Fortunately there’s a pattern which helps you maintain clear separation of concerns and loose coupling which lends itself well for ASP.NET WebForms, the Model-View-Presenter pattern.

The main concept behind the pattern is that you have a model you need to work with in your UI, a view which is the UI and a presenter which glues these two together. It’s pretty similar to MVC. I’ve created a sample project and hosted it on GitHub, all the code in this post can be found there. Continue reading “The Model-View-Presenter pattern”