Dienstvorgänge und Interceptors (ADO.NET Data Services-Framework)

Die ADO.NET Data Services ermöglichen die Definition von Dienstvorgängen und/oder Interceptoren, um das Zuordnungsmodell von URIs auf Ressourcen zu erweitern.

Einem Datendienst Geschäftslogik hinzufügen

Dienstvorgänge können zur Implementierung erforderlicher Geschäftslogik, wie zum Beispiel Validierungslogik oder Sicherheit, verwendet werden. Dienstvorgänge ermöglichen es dem Entwickler auf dem Server eine Methode zu definieren, die, ebenso wie andere Ressourcen von ADO.NET Data Service, von einem URI identifiziert wird. Diese Dienstvorgänge sind Methoden, die der von DataService abgeleiteten Klasse, die den Datendienst darstellt, hinzugefügt werden.

Erstellen von Dienstvorgängen

Um einen Dienstvorgang zu implementieren, definieren Sie eine öffentliche Instanz-Methode als Teil einer Klasse von Datendiensten, die von der DataService-Klasse, die den Datendienst darstellt, abgeleitet ist.

• Die Methode darf nur [in]-Parameter akzeptieren.

  • Wenn Parameter definiert wurden, muss der Typ eines jeden Parameters primitiv sein.

• Die Methode muss "void" zurückgeben, IEnumerable<T>, IQueryable<T>, T, oder eine primitive Klasse wie "ganze Zahl" oder "Zeichenfolge".

  • T MUSS eine Klasse sein, die einen Entitätstypen in dem durch den Datendienst verfügbar gemachten Datenmodell darstellt.

  • Um Abfrageoptionen wie Sortierung, Paging, und Filtern zu unterstützen, sollten die Methoden der Dienstvorgänge IQueryable<T> zurückgeben.

• Die Methode muss mit dem Attribut [WebGet] oder [WebInvoke] versehen sein.

  • [WebGet] aktiviert die aufgerufene Methode mit einer GET-Anforderung.

  • [WebGet] aktiviert die aufgerufene Methode mit einer PUT-, POST- oder DELETE-Anforderung.

• Ein Dienstvorgang kann mit dem Attribut SingleResultAttribute versehen sein, welches festlegt, dass der Rückgabewert der Methode eine einzige Entität, anstelle einer Auflistung von Entitäten, ist. Diese Unterscheidung legt die resultierende Serialisierung der Antwort fest. Wenn zum Beispiel die AtomPub-Serialisierung verwendet wird, ist ein einzelner Ressourcentyp als Eingangselement dargestellt, und eine Gruppe von Instanzen als Feed-Element.

Wenn eine Methode nicht nach den oben definierten Konventionen vorgeht, wird sie nicht als Dienstvorgang des Datendiensts verfügbar gemacht.

Adressierung von Dienstvorgängen

Gemäß der Spezifikation des ADO.NET Data Service Protocol, werden Dienstvorgänge durch Platzierung des Methodennamens im ersten Pfadsegment eines URI addressiert. In Abhängigkeit vom Rückgabetyp des Dienstvorgangs, können dem URI zusätzliche Pfadsegmente oder Abfrageoptionen hinzugefügt werden.

Gültige Rückgabetypen	URI-Regeln
Void	Es ist ein einzelnes Pfadsegment, das den Namen des Dienstvorgangs trägt, zugelassen. System-Abfrageoptionen sind nicht zulässig.
IEnumerable<T>	Es ist ein einzelnes Pfadsegment, das den Namen des Dienstvorgangs trägt, zulässig. System-Abfrageoptionen sind nicht zulässig.
IQueryable<T>	Zusätzliche URI-Pfadsegmente, die den Konstruktionsregeln in der ADO.NET Data Service-Spezifikationen-Spezifikation entsprechen, sind zulässig. System-Abfrageoptionen sind zulässig.

Hinzufügen von Dienstvorgängen

Im folgenden Beispiel wird ein Dienstvorgang in einen Datendienst implementiert, der ein Modell auf Basis eines Entity Framework verfügbar macht.

public class Northwind : 
           DataService<NorthwindModel.NorthwindEntities>
{
public static void InitializeService(IDataServiceConfiguration config)
    {
       // Entity sets access configuration.
        config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);

        // Service operations access configuration.
        config.SetServiceOperationAccessRule("OrdersByCity",
                  ServiceOperationRights.All);
        }

    [WebGet]
    public IQueryable<Orders> OrdersByCity(string city)
    {
        if (string.IsNullOrEmpty(city))
        {
            throw new ArgumentNullException("city",
                      "You must provide a city name argument");
        }

        return this.CurrentDataSource.Orders.Where(
            "it.ShipCity = @city", 
            new ObjectParameter("city", city));
    }
}

Um einen Dienstvorgang aufzurufen wird der folgende URI verwendet:

https://server/Northwind.svc/OrdersByCity?city='London'

Da der Rückgabetyp des Dienstvorgangs IQueryable<T> ist, sind zusätzliche URI-Segmente zulässig. Folgende URIs sind z. B. gültig:

https://server/Northwind.svc/OrdersByCity?city='London'&$top=2
https://server/Northwind.svc/OrdersByCity?city='London'&$top=10&$orderby=OrderID

Zugriffssteuerung für Dienstvorgänge

Dienstweite Sichtbarkeit der Dienstvorgänge wird durch eine Methode in der IDataServiceConfiguration-Klasse gesteuert, und zwar auf ähnliche Weise wie die Sichtbarkeit von Entitätenmengen. Um zum Beispiel die CustomersByCity-Methode des obigen Beispiels zugreifbar zu machen, wird der aus DataServic abgeleiteten Klasse, der Code aus der folgenden Darstellung hinzugefügt.

public class Northwind : DataService<NorthwindEntities>
    {
        public static void InitializeService(
                                   IDataServiceConfiguration config)
        {
            config.SetServiceOperationAccessRule("CustomersByCity", 
                                          ServiceOperationRights.All);
        }

        [WebGet]
        public IQueryable<Customer> CustomersByCity(string city)
        {… }
     }

Interceptoren

Die ADO.NET Data Services ermöglichen es dem Datendienstentwickler die Abfrage/Antwortpipeline zu unterbrechen und eine benutzerdefinierte Validierungslogik einzufügen. In den ADO.NET Data Services spielen die Interceptoren eine Doppelrolle: sie ermöglichen das Hinzufügen einer Validierungslogik zur Verarbeitungspipeline, und sie bieten eine Stelle an, an der benutzerdefinierte Autorisierungsrichtlinien auf Abruf eingefügt werden können.

Hinweis
Für Abfrageinterceptoren gibt es keine Parameter.

Abfrage-/URI-Verarbeitung

Wenn ein Datendienst eine GET-Anforderung erhält, wird der Anforderungs-URI verarbeitet, und alle im Datendienst definierten Abfrage-Interceptor-Methoden werden abgerufen. Im folgenden Beispiel wird dargestellt, wie eine Abfrage-Interceptor-Methode die GET-Anforderung für Aufträge abfängt. Dieser Interceptor gibt nur Aufträge zurück, die einem Kunden zugewiesen sind wenn CustomerID=="AROUT". Um den Benutzer der die Anforderung sendet zu authentifizieren, wäre mehr Code erforderlich. Dadurch könnte diese Methode Aufträge von jedem Benutzer zurückgeben.

    [QueryInterceptor("Orders")]
    public Expression<Func<Orders, bool>> FilterOrdersByCustomer()
    {
        return o => o.Customers.CustomerID == "AROUT";
    }

Siehe auch

Konzepte

Data Services-Erweiterungen (ADO.NET Data Services-Framework)
URI-Format für Adressressourcen (ADO.NET Data Services-Framework)

Weitere Ressourcen

Entity Data Model