Understanding Change Interceptors

Change interceptors are conceptually similar to query interceptors, but they differ in that they can intercept http requests of type POST, PUT, and DELETE (that is, CRUD operations via Uri). They are public methods returning no type; therefore, they are always Sub decorated with the ChangeInterceptor attribute pointing to the entity set name. Each interceptor receives two arguments: the data source (generally a single entity) and the System.Data.Services.UpdateOperations enumeration, which allows understanding what request was sent. Take a look at the following interceptor:

You decide how to handle the request depending on the UpdateOperations current value. Add corresponds to an insert operation, Delete to a delete operation, Change to an update operation, and None means that no operations were requested for the data source. The preceding code performs the same actions on both Add and Change operations and throws an exception if the new or existing order has null value in the OrderDate property. A different check is instead performed about Delete requests; in my example the code prevents from deleting an order whenever it has value in the ShippedDate property. No other code is required for handling situations in which supplied data are valid, because the Data Services framework automatically persists valid data to the underlying source. Change interceptors come in when a client application invokes the DataServiceContext.SaveChanges method. On the server side, change interceptors are raised just before sending data to the source and collecting information on the CRUD operation that sent the request.