Passing a user generated query down an n-tiered application.

Question

In my application I use my Data Access Layer (DAL) to generate Plan Old CLR Objects (POCO’s) which get sent to my Business Layer (BL). The BL then uses Model View ViewModel (MVVM) pattern to create object to bind to my Presentation Layer (PL).

I want to give my user the ability to filter data on the column level. For example http://demos.telerik.com/aspnet-ajax/grid/examples/generalfeatures/filtering/defaultcs.aspx

There are other grid controls that perform similar function but generally speaking this is the user experience I want to provide.

I have a large dataset so I want to do all the Paging/Sorting/Filtering on the server side.

It is trivial to send Paging/Sorting data down the n-tiered architecture to my DAL so I would only pull the records I am interested in.

I am however not sure how to send Filter data to my DAL, as a user can generate an arbitrarily long filter expression.

My Question is: What are my options for sending user generated filter expression through my n-tired application.

My Thoughts:

• My life would be easier if my data structure was the same as my objects structure which was also the same as the view’s I present my users. However my data structure can not be easily mapped to a users view like many of the control providers like to show in their example.
• Many of the Grid control providers offer server side functionality but they require one to use their Linq Providers. This would break many elements of my architecture.
• The Grid controls do generate an expression ‘string’, which I could pass to my DAL and have it interpret it. This however would couple my DAL to this particular control expression string format.
• I could create an ‘Expression Tree’ pass it as a parameter to my DAL. I would therefore only have to write a DAL interpreter for the expression tree once. Then for any Grid control I would have to generate to appropriate expression tree to pass it down.

Answer 1

Just an opinion, but I would avoid the parsing at any cost. I would also encourage strongly typed data whenever possible.

I'd go with the 'Expression Tree' idea myself. I've used this in large applications without much issue. We built our own implementation to represent the expression since we were on .Net 2.0 and didn't need a lot of support (equality only). I can't tell from your post if your considering building your own, but we came up with something like the following:

class ValueTriple { 
    System.Type FieldType;
    string Field;
    object Value;
}

class AndCritieria {
    ValueTriple[] Criteria;
}

class OrCriteria {
    AndCriteria[] Criteria;
}

We wrapped these classes with rich-type 'query' classes specific to an entity and eventually extended the OrCriteria with sorting/paging information. The query structure above gave us the ability to express any equality based condition regardless of complexity by essentially normalizing the input query structure. For instance:

WHERE x = '1' AND (y = '2' OR z = '3')

can also be represented as:

WHERE (x = '1' AND y = '2') OR (x = '1' AND z = '3')