Administrar el contexto del servicio de datos (Servicio de datos de WCF)
La clase DataServiceContext encapsula las operaciones admitidas en un servicio de datos determinado. Los servicios de OData carecen de estado, pero no ocurre lo mismo con el contexto. Por consiguiente, puede usar la clase DataServiceContext para mantener el estado en el cliente entre las interacciones con el servicio de datos para admitir características como la administración de cambios. Esta clase también administra las identidades y realiza el seguimiento de los cambios.
Opciones de combinación y resolución de identidad
Cuando se ejecuta el objeto DataServiceQuery<TElement>, las entidades de la fuente de respuesta se materializan en objetos. Para obtener más información, vea Materialización de objetos (WCF Data Services). La forma en que las entradas de un mensaje de respuesta se materializan en objetos se basa en la resolución de identidades y depende de la opción de combinación con la que se ejecutó la consulta. Cuando varias consultas o solicitudes de carga se ejecutan en el ámbito de un DataServiceContextúnico, el cliente Servicios de datos de Microsoft WCF solo realiza el seguimiento de una única instancia de objeto que tiene un valor de clave concreto. Esta clave, que se utiliza para realizar la resolución de identidades, identifica una entidad de forma inequívoca.
De forma predeterminada, el cliente solo materializa una entrada de la fuente de respuesta en un objeto para las entidades de las que aún no realiza un seguimiento DataServiceContext. Esto significa que los cambios en los objetos que ya están en la memoria caché no se sobrescriben. Este comportamiento se controla especificando un valor de MergeOption para las consultas y las operaciones de carga. Esta opción se especifica estableciendo la propiedad MergeOption en DataServiceContext. AppendOnly es el valor de la opción de combinación predeterminada. De este modo, solo se materializan los objetos de entidades de las que no se realiza un seguimiento, lo que significa que los objetos existentes no se sobrescriben. Otra manera de evitar que los cambios en los objetos del cliente se sobrescriban con las actualizaciones del servicio de datos es especificar PreserveChanges. Cuando se especifica OverwriteChanges, los valores de los objetos del cliente son reemplazados por los valores más recientes de las entradas de la fuente de respuesta, aunque se hayan realizado cambios en estos objetos. Cuando se utiliza una opción de combinación NoTracking, DataServiceContext no puede enviar los cambios realizados en los objetos de cliente al servicio de datos. Con esta opción, los cambios siempre se sobrescriben con valores del servicio de datos.
Administrar la simultaneidad
OData admite la simultaneidad optimista que permite al servicio de datos detectar conflictos de actualización. El proveedor del servicio de datos se puede configurar de manera que el servicio de datos compruebe los cambios en las entidades mediante un token de simultaneidad. Este token incluye una o más propiedades de un tipo de entidad que el servicio de datos valida para determinar si un recurso ha cambiado. El cliente de Servicios de datos de Microsoft WCF administra los tokens de simultaneidad, que se incluyen en el encabezado eTag de las solicitudes al servicio de datos y las respuestas de este. para obtener más información, vea Actualizar el servicio de datos (WCF Data Services).
DataServiceContext realiza el seguimiento de los cambios realizados en los objetos notificados manualmente utilizando AddObject, UpdateObject y DeleteObject o mediante DataServiceCollection<T>. Cuando se llama al método SaveChanges, el cliente envía de nuevo los cambios al servicio de datos. Se puede producir un error en SaveChanges cuando los cambios de datos en el cliente entran en conflicto con los cambios en el servicio de datos. Cuando esto sucede, debe consultar de nuevo el recurso de entidad para recibir los datos actualizados. Para sobrescribir los cambios en el servicio de datos, ejecute la consulta con la opción de combinación PreserveChanges. Al llamar de nuevo al método SaveChanges, los cambios conservados en el cliente se mantienen en el servicio de datos, siempre que no se hayan realizado otros cambios en el recurso del servicio de datos.
Guardar los cambios
El seguimiento de los cambios se realiza en la instancia de la clase DataServiceContext, pero los cambios no se envían al servidor inmediatamente. Una vez que haya efectuado los cambios necesarios de una actividad determinada, llame al método SaveChanges para enviar todos los cambios al servicio de datos. Se devuelve un objeto DataServiceResponse cuando finaliza la operación SaveChanges. El objeto DataServiceResponse incluye una secuencia de objetos OperationResponse que, a su vez, contienen una secuencia de instancias de EntityDescriptor o LinkDescriptor que representan los cambios que se guardaron o se intentaron realizar. Cuando se crea o modifica una entidad en el servicio de datos, la instancia de la clase EntityDescriptor contiene una referencia a la entidad actualizada, que incluye los valores de propiedad generados por el servidor, como el valor de ProductID generado en el ejemplo anterior. La biblioteca cliente actualiza automáticamente el objeto de .NET Framework para que tenga estos nuevos valores.
En el caso de las operaciones de inserción y actualización correctas, la propiedad de estado del objeto EntityDescriptor o del objeto LinkDescriptor asociado a la operación se establece en Unchanged y los nuevos valores se combinan mediante OverwriteChanges.
Cuando una operación de inserción, actualización o eliminación produce un error en el servicio de datos, el estado de la entidad permanece como estaba antes de que se llamara al método SaveChanges y la propiedad Error de OperationResponse se establece en una instancia de DataServiceRequestException que contiene información sobre el error. Para obtener más información, vea Actualizar el servicio de datos (WCF Data Services).
Administrar solicitudes
El protocolo OData proporciona flexibilidad en los comportamientos de solicitudes y respuestas de un servicio de datos. La biblioteca cliente le permite aprovechar esta flexibilidad controlando cómo interactúa su aplicación con el servicio de datos.
Establecer el encabezado Prefer para las operaciones de cambio
De forma predeterminada, una carga de mensaje solo se devuelve en respuesta a una solicitud POST para crear una nueva entidad. En este caso, la nueva entidad se devuelve en la carga. Esto significa que cuando se realizan actualizaciones a los objetos, la entidad actualizada no se devuelve en la carga o el mensaje de respuesta. Sin embargo, el protocolo OData establece que un cliente puede utilizar el encabezado Prefer para solicitar un cambio de este comportamiento predeterminado. El encabezado Prefer en una solicitud POST, PUT, PATCH o MERGE lo genera DataServiceContext basándose en el valor de DataServiceResponsePreference establecido en la propiedad AddAndUpdateResponsePreference. En la siguiente tabla se muestran las opciones del encabezado Prefer y los comportamientos de respuesta relacionados:
Valor del encabezado Prefer |
Valor de AddAndUpdateResponsePreference |
Comportamiento de la respuesta |
|---|---|---|
No incluido en la solicitud. Este es el comportamiento predeterminado. |
Una carga de respuesta solo se devuelve para las solicitudes POST y no para las solicitudes PUT, PATCH y MERGE. |
|
return-content |
Una carga de respuesta se devuelve para todas las solicitudes de cambio. |
|
return-no-content |
No se devuelve ninguna carga de respuesta para ninguna solicitud. Para una solicitud POST, el servicio de datos incluye también un encabezado DataServiceId en la respuesta. Este encabezado se utiliza para comunicar el valor de clave a la entidad recién creada. |
Nota
Incluso cuando el servicio de datos admite una versión del protocolo OData que admite el encabezado Prefer, un servicio de datos puede decidir no respetar estos tipos de preferencias de procesamiento de solicitudes.
Establecer el método HTTP para las actualizaciones
De forma predeterminada, la biblioteca cliente de .NET Framework envía actualizaciones a las entidades existentes como solicitudes MERGE. En OData, una solicitud MERGE actualiza las propiedades seleccionadas de la entidad; sin embargo, el cliente siempre incluye todas las propiedades en la solicitud MERGE, incluso las propiedades que no hayan cambiado. El protocolo OData también admite el envío de solicitudes PUT y PATCH para actualizar entidades. En una solicitud PUT, una entidad existente se reemplaza básicamente por una nueva instancia de la entidad con valores de propiedad desde el cliente. Las solicitudes PATCH se administran de la misma manera que las solicitudes MERGE; sin embargo, PATCH es una acción HTTP estándar, mientras que MERGE es definida por OData. Este comportamiento de actualización se especifica proporcionando el valor ReplaceOnUpdate, para utilizar solicitudes PUT, o el valor PatchOnUpdate, para utilizar solicitud PATCH, como opciones al llamar a SaveChanges(SaveChangesOptions).
Nota
Una solicitud PUT se comportará de forma distinta que una solicitud MERGE o PATCH cuando el cliente no conozca todas las propiedades de la entidad.Esto puede ocurrir cuando se proyecte un tipo de entidad en un nuevo tipo en el cliente.También puede ocurrir cuando se hayan agregado nuevas propiedades a la entidad del modelo de datos del servicio y la propiedad IgnoreMissingProperties de la clase DataServiceContext se establezca en true para ignorar tales errores de asignación de cliente.En estos casos, una solicitud PUT restablecerá las propiedades que desconozca el cliente en sus valores predeterminados.
Tunelización POST
De forma predeterminada, la biblioteca de clientes envía solicitudes de creación, lectura, actualización y eliminación a un servicio de OData utilizando los métodos HTTP correspondientes de POST, GET, PUT/MERGE/PATCH y DELETE. Esto mantiene los principios básicos de Transferencia de datos de representación (REST, Representational State Transfer). Sin embargo, no todas las implementaciones del servidor web admiten el conjunto completo de métodos HTTP. En algunos casos, los métodos compatibles podrían estar restringidos solo a GET y POST. Esto puede ocurrir cuando un intermediario, como un firewall, bloquea las solicitudes con ciertos métodos. Como los métodos GET y POST se admiten con más frecuencia, OData prescribe una manera de ejecutar cualquier método HTTP no compatible utilizando una solicitud POST. Conocida como tunelización de método o tunelización POST, permite a un cliente enviar una solicitud POST con el método real especificado en el encabezado X-HTTP-Method personalizado. Para habilitar POST tunelizado para las solicitudes, establezca la propiedad UsePostTunneling en la instancia de DataServiceContext en true.
Resolver el URI base de los conjuntos de entidades
De forma predeterminada, el cliente supone que todos los conjuntos de entidades, también conocidos como colecciones, comparten el mismo URI base. La propiedad BaseUri define este URI base en DataServiceContext. Sin embargo, el protocolo OData permite que un servicio de datos exponga conjuntos de entidades como colecciones que tienen URI base diferentes. Para controlar conjuntos de entidades con URI base diferentes, el cliente le permite registrar un delegado con DataServiceContext que se puede utilizar para resolver los URI base de varios conjuntos de entidades. Este delegado es un método que toma una cadena (el nombre del conjunto de entidades) y devuelve un Uri (el URI base para el conjunto de entidades especificado). Esta resolución se registra con DataServiceContext por asignación a la propiedad ResolveEntitySet. Una implementación de resolución de ejemplo podría, cuando se crea el contexto, leer la información sobre las colecciones que es devuelta por la raíz del servicio de datos y almacenar los valores del URI base de cada colección en un diccionario. La resolución podría utilizar a continuación este diccionario para devolver el URI de un conjunto de entidades concreto. Para obtener un ejemplo más completo, incluido el código de ejemplo, vea la entrada de blog relacionada con la resolución de conjuntos de entidades.
Requisitos de control de versiones
Los comportamientos de DataServiceContext tienen los siguientes requisitos de versión del protocolo OData:
La compatibilidad con el encabezado Prefer y las solicitudes PATCH requieren que tanto el cliente como el servicio de datos admitan la versión 3.0 del protocolo OData y versiones posteriores.
La compatibilidad con resoluciones de conjuntos de entidades requiere la versión de la biblioteca cliente de Servicios de datos de Microsoft WCF que está incluida con el lanzamiento de Data Framework o una versión posterior.
Para obtener más información, vea Control de versiones del servicio de datos (Servicios de datos de Microsoft WCF).