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?