Passing a custom request down an n-tier application
In my application, I use my Data Access Layer (DAL) to create Plan Old CLR Objects (POCOs) that are sent to my Business Layer (BL). BL then uses the Model View ViewModel (MVVM) pattern to create an object to bind to my View Layer (PL).
I want to give my user the ability to filter data at the column level. For example http://demos.telerik.com/aspnet-ajax/grid/examples/generalfeatures/filtering/defaultcs.aspx
There are other grid controls that serve a similar function, but generally 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 over n-tier architecture to my DAL, so I would only pull the records of interest for me.
However, I'm not sure how to send the filter data to my DAL, as the user can generate an arbitrarily long filter expression.
My question is: What are my options for sending a user-expressed 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 views that I present to my users. However, my data structure cannot be easily mapped to the user's view, for example many of the control providers like to show in their example.
- Many of the grid management providers offer server-side functionality, but they require one to use Linq Providers. This will break many elements of my architecture.
- The grid controls generate an expression "which I could go to my DAL and interpret it. It. This, however, would connect my DAL to this particular control expression. String format."
- I could create an "Expression Tree" and pass it as a parameter to my DAL. I would therefore need to write a DAL to express the tree once. Then for any grid control I would have to generate an appropriate expression tree this down.
source to share
Just an opinion, but I would avoid parsing at all costs. I would also recommend strongly typed data whenever possible.
I'll go myself with the Expression Tree idea. I've used this in large applications without too much trouble. We created our own implementation to represent the expression since we were on .Net 2.0 and didn't need much support (equality only). I can't tell from your post if you're planning on building your own, but we've come 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 object-specific "rich" query classes and eventually extended the OrCriteria with sort / paging information. The query structure above gave us the ability to express any condition based on equality, regardless of complexity, essentially normalizing the structure of the input queries. For example:
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')
source to share