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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s