I was reading about query interceptors. I was disappointed because thats more like a filter instead of an interceptor. In other words you can eather include records or not include them. You are not able to modify records for instance.
If I want to create a query interceptor for my entity Users
I could then do something like:
[QueryInterceptor("Users")] // apply to table users
public Expression<Func<User, bool>> UsersOnRead()
{
return cust => cust.IsDeleted == false;
}
What if I instead create the operation: NOTE IS VERY IMPORTANT TO HAVE THE OPERATION NAME JUST LIKE THE ENTITY NAME OTHERWISE IT WILL NOT WORK
[WebGet]
public IEnumerable<User> Users()
{
return this.CurrentDataSource.Users.Where(x=>x.IsDeleted==false);
}
Placing this method instead of the query interceptor makes my service behave exactly the same. Plus I have more power! Is taking this approach a better solution?
I played around a little more with this and one of the issues is navigation properties won't be filtered. Let's say you have an entity called SalesPeople that has a link into IEnumberable of Customers
If you do
when you query your OData feed like WCFDataService.svc/SalesPeople?$expand=Customers the results set for Customers will still have the filter applied.
But this
When running OData query like WCFDataService.svc/Customers you will have the filtered list on active customers, but when running this WCFDataService.svc/SalesPeople?$expand=Customers the results set for the Customers will include deleted customers.