+1  A: 

If you aren't using a DB to store your object, everything else is the same except the "generate a SQL query" part. What you should look at is the Specification Pattern. Your specification objects basically have a single method called IsSatisfiedBy that takes in the object to see if it meets the specification. Adding some kind of parameter to the specification based on user input seems like a pretty trivial exercise and sounds like it would work in your case.

Not sure I understand the part about "mappings" but since you're not generating a raw SQL query, just make sure your specification objects are serializable and persist it however you want.

LINQ can do this as can plain ol' C# or Java.

David Archer
might be useful to mix a scripting engine into this (like Rhino perhaps) to allow the user to build the specification. This is really no more than a glorified, configurable filter, eh? Unless there are optimizations that can be made using indexes, filtering the pool of objects is what's going to be required.
Kevin Day
A: 

Are you trying to make a data-driven solution, one that can be arbitrarily modified by the user or someone else, or are you looking for something driven internally.

The user driven solution has infinite possibilities that are not known at build time, but it needs some sort of UI. You must tie the solution to the UI (for instance, show a table and allow them to click to sort on a given row/rows and perhaps let them enter "Filter Criteria" per row) so I'm not sure what advantage your search would provide..

The internally driven solution has a fixed number of possibilities that are all known at build time. You can code each one up pretty easily--Maybe not as easily as doing it the way you are describing, but not too much more difficult since there are a limited number of solutions you have to implement.

Bill K