Betrieb statt Abfrage-Interceptor (WCF Data Services)
Posted: 23 Dec 2024, 11:31
Ich habe über Abfrage-Interceptoren gelesen. Ich war enttäuscht, weil das eher ein Filter als ein Abfangjäger ist. Mit anderen Worten: Sie können Datensätze entweder einschließen oder nicht einschließen. Sie können beispielsweise keine Datensätze ändern.
Wenn ich einen Abfrage-Interceptor für meine Entitätsbenutzer erstellen möchte, könnte ich dann Folgendes tun:
[QueryInterceptor("Users")] // apply to table users
public Expression UsersOnRead()
{
return cust => cust.IsDeleted == false;
}
Was passiert, wenn ich stattdessen die Operation erstelle: HINWEIS: Es ist sehr wichtig, dass der Name der Operation genau so ist wie der Name der Entität, andernfalls wird es so sein FUNKTIONIERT NICHT
[WebGet]
public IEnumerable Users()
{
return this.CurrentDataSource.Users.Where(x=>x.IsDeleted==false);
}
Wenn ich diese Methode anstelle des Abfrage-Interceptors platziere, verhält sich mein Dienst genau gleich. Außerdem habe ich mehr Power! Ist dieser Ansatz eine bessere Lösung?
Wenn ich einen Abfrage-Interceptor für meine Entitätsbenutzer erstellen möchte, könnte ich dann Folgendes tun:
[QueryInterceptor("Users")] // apply to table users
public Expression UsersOnRead()
{
return cust => cust.IsDeleted == false;
}
Was passiert, wenn ich stattdessen die Operation erstelle: HINWEIS: Es ist sehr wichtig, dass der Name der Operation genau so ist wie der Name der Entität, andernfalls wird es so sein FUNKTIONIERT NICHT
[WebGet]
public IEnumerable Users()
{
return this.CurrentDataSource.Users.Where(x=>x.IsDeleted==false);
}
Wenn ich diese Methode anstelle des Abfrage-Interceptors platziere, verhält sich mein Dienst genau gleich. Außerdem habe ich mehr Power! Ist dieser Ansatz eine bessere Lösung?