If the incoming query is for CustomerDto, but the underlying IQueryable is against Customer, then we have two options.
1. Apply the IQ against the converted CustomerDto list using Queryable attribute.
[Queryable]
IEnumerable<CustomerDto> Get()
{
return CustomerList.Select(customer => ToDtoCustomer(customer));
}
Now this is bad because you ended up buffering all the customers. Imagine you have 10,000 customers, I only need the first 20 customers ordered by their Name property. This would bring in all the Customer’s and turn them into CustomerDto’s, and then order them using Name property on CustomerDto. ( note, Customer might not have Name property, but it has FirstName and LastName );
2. Now a much better implementation would try to apply the IQueryable against CustomerList, and then convert the result into CustomerDto’s.
However, this requires mapping the original AST ( filterQueryOption.FilterClause ) to turn it to a new FilterClause that works with Customer. Then turn the FilterClause’ into Expression, and apply it against CustomerList.
This is a pretty difficult now, and I think it will be a great exercise to make it simpler. Couple of thoughts:
1. Have a tree visitor class that could let people not only validate, but also *convert*;
2. Make our FilterBinder class public, or make our FilterClause on filterqueryoption settable;
Comments: dup of 839.
1. Apply the IQ against the converted CustomerDto list using Queryable attribute.
[Queryable]
IEnumerable<CustomerDto> Get()
{
return CustomerList.Select(customer => ToDtoCustomer(customer));
}
Now this is bad because you ended up buffering all the customers. Imagine you have 10,000 customers, I only need the first 20 customers ordered by their Name property. This would bring in all the Customer’s and turn them into CustomerDto’s, and then order them using Name property on CustomerDto. ( note, Customer might not have Name property, but it has FirstName and LastName );
2. Now a much better implementation would try to apply the IQueryable against CustomerList, and then convert the result into CustomerDto’s.
However, this requires mapping the original AST ( filterQueryOption.FilterClause ) to turn it to a new FilterClause that works with Customer. Then turn the FilterClause’ into Expression, and apply it against CustomerList.
This is a pretty difficult now, and I think it will be a great exercise to make it simpler. Couple of thoughts:
1. Have a tree visitor class that could let people not only validate, but also *convert*;
2. Make our FilterBinder class public, or make our FilterClause on filterqueryoption settable;
Comments: dup of 839.