The easiest way is to add the search / sort / filter parameters to the argument list of the method and add the appropriate LINQ query operators to your data context request in the service method. However, in this case, you will lose the IQueryable
functions on the client side. I mean, client requests will be available only for the application server, but will not get into the database. And you need some layer between the DomainContext
and the user interface: DomainDataSource
unlikely to work.
Displaying query results as IQueryable
using AsQueryable()
will not help, because expression trees will be unconditionally compiled into code to execute your LINQ-to-Objects statements.
It is somewhat more difficult to use arguments, as in the first case, together with creating your own IQueryable
shell over the client-side query object. This shell will extract parameters from query expressions and pass them to the service as method arguments. Well, I would try this if I had enough free time.
Another tricky way is a similar server side. It is possible to get an IQueryable
object that has an expression tree passed from the client to the DomainService
. You need to override the DomainService.Query
method. Then you can extract the part of the query expression related to the search call / sort, save it in the field and then apply to the database query. However, the Query
method is the only one for all methods in the specified DomainService
. Therefore, you will probably end up with a large table method that decides what to do for each of the service request methods. Needless to say, the service will become very complex.
In conclusion, I highly recommend you the first option.
source share