Extending WCF Data Service to synthesize missing data on request

I have got a WCF Data Service based on a LINQ to SQL data provider.

I am making a query "get me all the records between two dates".

The problem is that I want to synthesize two extra records such that I al开发者_JAVA百科ways get records that fall on the start and end dates, plus all the ones in between which come from the database.

Is there a way to "intercept" the request so I can synthesize these records and return them to the client?

Thanks

I suspect the answer involves using "Interceptors".

Just stumbled across this... http://msdn.microsoft.com/en-us/library/dd744842.aspx

The more I think about this the more I would say "please don't do this". The problem is that in WCF Data Services (or OData for that matter), each entity you return (entity == record) needs to have its unique URI. The clients also assume that if the entity is returned from the server (unless it was deleted), the entity can be accessed again. In your case though, the boundary entities are defined by the query and they really only exist in the context of the query. Given a different query they are different. So all in all, they do not behave like entities, they behave more like some kind of query metadata.

Anyway, if you really think this is the right thing to do... It's rather hard to do this. The only approach I can think of is to hook into the IQueryable returned from the entity set (layer your own IQueryable on top of the one from LINQ to SQL). Then when a query gets executed, you parse the expression tree and find the conditions which define the range, then you return a custom implementation of IEnumerable which will "synthesize" the two special entities at the begining and at the end and it will return the rest from the underlying LINQ to SQL results. All of this is lot of code and it's definitely not easy to do.

A second possible way would be to implement this as a Service operation (requires that the client knows that there's a special operation on the server to do this though). It would also make a bit more sense, as the service operation would get the range as its parameters instead of as a filter and thus is much easier for you to figure out the range (no expression tree parsing).