I was thinking about a scenario which is often seen. Let's start form the user perspective. He/she opens a web page and there is some data table and filters like that:
Filter by: equals <input value here>

User chooses a field name and enters some value and submits that.

Web application (presentation layer) takes user input and transfers the request to the web service (using automatic .NET XML serialization). So it seems data transfer object pattern can be used here.

Then my web service transforms that DTO to some valid query. Let's assume we are using some OR/M tool to query it for objects which satisfies the query. Also let's assume that OR/M tool offers some easy way to construct dynamic queries (BTW, LINQ-to-SQL has some problems with this).

So the question is - how to better pass data from user form to the data access layer (OR/M tool) so the dynamic query could be generated with less hassle? It would be awful to have web method for each field like this: GetCustomerByName(string name), GetCustomerByCity ... and so on. Then I have to analyze the user input and call appropriate web method. But maybe it is the right way?

I prefer some method GetCustomersByFilter, so then I can almost directly pass the request to web service and then can convert the request to query in OR/M servicing component. But what to pass to this GetCustomersByFilter method? Dictionary with field names as keys? Many nullable parameters? Custom objects?

It would be nice to use the same data structures that are used to pass data to the web application - the same data transfer objects, I guess. Like this:
Customer[] GetCustomersByFilter(Customer filter);

but then I have to allow all the fields of Customer to be nullable so I can later see which fields are used as filters. And if that does not correspond my business/validation rules (if rules say - some property cannot be null) than it would be a bit confusing. Also if I would like to use some generator to create web forms based on my DTO objects, it would be impossible to mark required fields easily just by detecting if some field is nullable or not.

So maybe I need some other object, like CustomerFilter with all nullable fields? Wouldn't it be overkill to have two classes for each object (also, accounting that those DTOs are converted to domain entities later - then we have even more classes)?

This dynamic filtering issue is really bugging me. Has anybody any experience with that, especially using domain driven design?


I'll try to explain it better, I guess my previous post was a bit vague.

I have a three-tier application. One tier is a presentation layer which can be a standard ASP.NET Web application with web forms.
The data source for those forms live on some other tier - web server which is accessible through a .NET Web service, which inside processes business logic and accesses a data base using some DAL library or OR/M tool. I mentioned OR/M tool just to accent that this is not some straight-forward ADO.NET usage scenario - there is some data base abstraction layer involved.

And here is the problem - what is a better way / best practice, how to pass a dynamic request for data from the presentation tier to that Web service?
I say "dynamic request" because I do not know, what the user will chose as a filter - which field and what value, so I cannot use some simple web service methods like GetSomeEntitiesBySomeField(fieldValue) because then I need a method for each field and for all objects which can be filtered dynamically.