Betrieb statt Abfrage-Interceptor (WCF Data Services)

Post a reply

Smilies
:) :( :oops: :chelo: :roll: :wink: :muza: :sorry: :angel: :read: *x) :clever:
View more smilies

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Betrieb statt Abfrage-Interceptor (WCF Data Services)

by Anonymous » 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?

Top