I recently ran into a situation where I needed to generate a dynamic query using the Entity Framework. I needed to come up with a way to simulate an “OR” type of operation. I started down the path of trying to figure out how to generate Expression Trees, and I stumbled across a fantastic library that already does this called PredicateBuilder.

The best way to show this is through example. I whipped up a sample database to show exactly what I mean. This is a simple example, but hopefully you get the idea.

I’ve created 3 tables, one for shirts, 1 for size, and 1 for color. I dumped some dummy data into the tables, and away we go.

After dropping in a quick entity data model and putting in some test data, I’m ready to start querying the model.

Here is a quick look at what the sample data looks like for reference:

Now, suppose we have a user interface where the user can query this data however they want to. How do we go about coding this? For example, say we wanted to get the list of all shirts that were either red or yellow, regardless of size?

First, our basic UI:

I just threw a quick web form together to get this data. It looks like this:

First, I put together a quick repository to access the data. I needed methods to load all of the colors and sizes for the UI, and I put in methods to load each by ID so I can figure out which ones are selected.

The next part is figuring out how to dynamically query the data set, which is where PredicateBuilder really shines. The key difficulty is that I have no idea which color/size combinations that they are going to pick. I can’t just chain together where clauses in the Entity Framework, because those don’t behave like “OR” operations, they are “AND” operations. Therefore, if I check both red and yellow on the user interface and run the query, it won’t get any results because the shirt can’t be both red and yellow.

To get PredicateBuilder up and going, I first created a wrapper class so I can store which colors and sizes that the user checked. It looks like this:

I am returning an IQueryable of type Shirt from the method. I included a reference to LinqKit.dll, which I downloaded from this page. When performing “OR” operations, you need to initiate the predicate to PredicateBuilder.False<T>, where T is the type of data you are looking for. As you can see, I just loop through the collections and “OR” the predicates together for any color or size that is checked.

The next thing to point out is the AsExpandable() method that is chained to the IQueryable<Shirt>. This is required by PredicateBuilder, as explained on the project site. That’s really all there is to it.

I am just running the query and binding the results to a grid I put down on the page. To test it, I ran a few queries. The first query I wanted was to get any shirt back that was red or yellow, regardless of size. I did this by checking the red and yellow checkboxes and hitting the Run Query button. This gave me 4 shirts, which is what I expected when looking at the data above.

Next, I wanted to perform a query that used both color and size. I wanted to find any black shirt that was either large or 2XL. After running this query, I got the expected 2 results back, as seen here:

This project was a really nice find for me, it saved me a lot of time that I thought I was going to have to spend writing an Expression Tree generator. You can hopefully see from this example how powerful this library is.

I was recently working on an MVC application and I ran into a problem. I was creating a ValidationAttribute and I needed to have access to my repository in this attribute. The use case is that I want to add a release of an application, and I want to make sure that the ID being passed in is actually a valid application. My first pass at this was to try and use property injection, like this:

The problem here is that because of the way attributes are instantiated, this injection method does not work. In the above code sample, when this gets executed my AppRepo is null.

Service Locator

The solution to my problem ended up being the use of a service locator to handle my injection. I could have went with the Common Service Locator library, but that isn’t exactly what I want. I already know what DI container I want to use, so completely abstracting that layer away isn’t what I need. I ended up creating a library to handle the wiring up of Ninject, and to basically act as a wrapper to access the Ninject kernel.

Don’t Abuse It

I try to only use my service locator container when I have to. I use standard property or constructor injection whenever possible, but this does provide a nice way to be able to inject into my ValidationAttribute classes.