I've got a basic business class that contains methods for getting a customer by ID, etc. I understand enough about n-Tier to have the UI request a dataset from the BizObj method, which in turn requests the DataSet from a database stored procedure, optionally through a data-tier class (some would argue that's not optional, but that's not the point here).

I want to add a .Search() method to this hierarchy and I want it to accept a set of value pairs for all of the search criteria that the user supplies. It would help if you picture in your mind a search page where the user can enter as much or as little as they know about what they are trying to find -- say 1-20 different criteria, each of which maps to a column. [Aside: It seems that once I have this method coded, all of the specific Get* methods could make use of it too, unless we're using specific stored procedures for some or all of those Get* methods of course.]

The value pairs ultimately map to column criteria in a WHERE clause, but can be translated on the way down so that they are English/general at the BizObj level and database-specific down at that level. For example, something like this coded at the UI level:

<LastName>Conway</LastName>

Might be translated into this at the database-specific level:

clast_nm='Conway'

My design question is what kind of parameter(s) should I pass to Search to make this flexible and easy for the caller? Some options I've thought of already include:

- a System.string containing Xml node/value pairs. The advantage here would seem to be that I could use an attribute to specify operators (= might be the default, but what if a UI allows the user to somehow specify other operators such as >, LIKE, etc?). In some cases, maybe even AND/OR conditions would be allowed. A basic example of this Xml string would look something like this, I guess:

<search>
  <lastname>Conway</lastname>
  <firstname operator='LIKE'>K</firstname>
  <state>MO</state>
</search>

- a System.Collection.HashTable containing key/value pairs that map to columns and search values. The advantage here is that this would be relatively easy for the caller (ASP.NET page, Web Service, Windows form, etc.) to create. By "overloading" the value, I could also have it contain operator information, I guess. E.g., HashTable.Add("lastname","C~~LIKE") could indicate that the user specified a wildcard search for clients having lastnames starting with C. That seems kludgy, but would avoid the need/overhead to parse Xml.

Clearly, I could overload Search() so that either of the above could be passed, if that turns out to be advantageous.

What are some of you doing for flexible search methods or what other designs might you recommend for this?

Thanks.
Kelly