Service operations can be used when business logic is required, for example to implement validation logic or security. Service operations allow the developer to define a method on the server, which, like other ADO.NET Data Service resources, is identified by a URI. These service operations are methods added to the class derived from DataService that represents the data service.

To implement a service operation, define a public instance-method as part of the data service class derived from the DataService class representing the data service.

• The method must accept only [in] parameters.

  • If parameters are defined, the type of each parameter must be a primitive type.

• The method must return void, IEnumerable<T>, IQueryable<T>, T, or a primitive class such as integer or string.

  • T MUST be a class that represents an entity type in the data model being exposed by the data service.

  • In order to support query options such as sorting, paging, and filtering, service operation methods should return IQueryable<T>.

• The method must be annotated with the [WebGet] or [WebInvoke] attribute.

  • [WebGet] enables the method to be invoked using a GET request.

  • [WebInvoke] enables the method to be invoked using a PUT, POST, or DELETE request.

• A service operation may be annotated with the SingleResultAttribute that specifies that the return value from the method is a single entity rather than a collection of entities. This distinction dictates the resulting serialization of the response. For example, when using AtomPub serialization, a single resource type instance is represented as an entry element and a set of instances as a feed element.

If a method does not follow the conventions defined above, it will not be exposed as a service operation within the data service.

Addressing Service Operations

Adding Service Operations

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));
    }
}

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

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

Service Operations Access Control

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

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

Interceptors

ADO.NET Data Services enable a data service developer to intercept the request/response pipeline and inject custom validation logic. In ADO.NET Data Services, interceptors play a dual role; they enable validation logic to be added to the processing pipeline and provide a place to insert custom authorization policy on a per request basis.

Note
Query interceptors cannot take parameters.

Request/URI Processing

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

Concepts

Other Resources