A data access class that allows iquiryable filtering on all properties of the returned ienumerable object
I find that when ever you have a data access class that implements an interface the interface provides all expected return properties but often in order for those properties to be filterable you're required to do one of two things. Most often I'll turn my initial iquiryable object set to an ienumerable set stored in memory. Then I'll have another class that allows for filtering on the result of the initial query. This unfortunately might lead to scenarios where an initial memory set is huge but the resultant set once all filters have been taken into account is small. The second possibility is your data access class takes in all expected filterable element values. This allows the iquiryable to consider them in the initial look up. However as soon as you choose to filter on a new element, even if that property is part of the initial object you need to edit your existing look up class with a new function or create a new class with the new expected filter properties as either arguments to the function or as properties that get used in the evaluation of the interface function.
What I'd like is a class that you provide the expected output object (probably as a generic type on the class) and then from the application side you can provide the list of properties you want to filter on as well as the values for those filters from the properties of the expected result object. The class will then turn the expected result property filters into filters on the source data set so that the filters can be used on the initial iquiryable where statements without updating the data access class when ever a new filter is requested. The assumption is that this would be the case as long as the filter being applied is on the properties of the returned result object and not new properties as any new properties would obviously require an update to the data access class anyway to connect that property to it's source data.
The idea is that the application might not be aware of the source data set the result object is generated from but the class doing the generation should know the source dataset logic that is used to calculate the resultant object property and should be able to make that transition.
For example if I want from my data access class/function returning an ienumerable of class R which has properties A, B, and C. The class builds the class R enumerable from an entityframework entity S. S.a goes to R.A, S.d + S.e goes to R.B, and Substring(S.z,0,5) goes to R.C
Knowing this if I want to filter on R.b where b = 5 really I want to filter on S.d + S.e = 5. The application doesn't know this but the class it trusts to get this result should be able to make that jump on its own.
If for some reason I wanted to add a few new properties to R, I wouldn't expect the existing class to be able to make that jump without an update to it to account for that newly added result properties. Ideally by making those updates to add the new properties to the result set. This also handles the possibility of filtering on those properties in the future when ever the application desired. All on the iquiryable side.
Does anyone know of any existing data structures that already do this or had anyone built anything to solve the same architectural issues that would be willing to share their experience?