Gérer le contexte du service de données (WCF Data Services)

Remarque :
Cette rubrique décrit nouvelle fonctionnalité dans WCF Data Services. Cette nouvelle fonctionnalité prend en charge version 3 du Open Data Protocol (OData) et est disponible sous forme de mise à jour à .NET Framework version 4. Vous pouvez télécharger et installer la mise à jour à partir du Centre de téléchargement Microsoft.

La classe DataServiceContext encapsule des opérations prises en charge sur un service de données spécifié. Même si les services OData sont sans état, ce n'est pas le cas du contexte. Par conséquent, vous pouvez utiliser la classe DataServiceContext pour conserver l'état sur le client entre des interactions avec le service de données afin de prendre en charge des fonctionnalités telles que la gestion des changements. Cette classe gère également des identités et suit les modifications.

Options de fusion et résolution d'identité

Lorsqu'un objet DataServiceQuery est exécuté, les entités du flux de réponse sont matérialisées en objets. Pour plus d'informations, consultez Matérialisation d'objets (WCF Data Services). La façon dont les entrées d'un message de réponse sont matérialisées en objets dépend de la résolution d'identité et de l'option de fusion sous laquelle la requête a été exécutée. Lorsque plusieurs requêtes ou demandes de chargement sont exécutées dans l'étendue d'un objetDataServiceContext unique, le client Services de données WCF ne suit qu'une seule instance d'un objet qui a une valeur de clé spécifique. Cette clé, utilisée pour effectuer la résolution d'identité, identifie une entité de façon unique.

Par défaut, le client ne matérialise qu'une seule entrée du flux de réponse en un objet pour les entités qui ne sont pas déjà suivies par l'objet DataServiceContext. Cela signifie que les modifications apportées à des objets déjà dans le cache ne sont pas remplacées. Ce comportement est contrôlé en spécifiant une valeur MergeOption pour les requêtes et les opérations de chargement. Cette option est spécifiée en définissant la propriété MergeOption sur l'objet DataServiceContext. La valeur de l'option de fusion par défaut est AppendOnly. Cela ne matérialise les objets que pour les entités qui ne sont pas déjà suivies, ce qui signifie que les objets existants ne sont pas remplacés. Il existe un autre moyen d'empêcher que les modifications apportées aux objets sur le client ne soient remplacées par les mises à jour provenant du service de données. Il consiste à spécifier PreserveChanges. Lorsque vous spécifiez OverwriteChanges, les valeurs des objets sur le client sont remplacées par les valeurs les plus récentes à partir des entrées du flux de réponse, même si les modifications ont déjà été apportées à ces objets. Lorsqu'une option de fusion NoTracking est utilisée, l'objet DataServiceContext ne peut pas transmettre au service de données les modifications apportées aux objets clients. Avec cette option, les modifications sont toujours remplacées par les valeurs du service de données.

Gestion de l'accès concurrentiel

OData prend en charge l'accès concurrentiel optimiste qui permet au service de données de détecter des conflits de mise à jour. Le fournisseur de services de données peut être configuré de telle façon que le service de données recherche les modifications apportées aux entités à l'aide d'un jeton d'accès concurrentiel. Ce jeton comprend une ou plusieurs propriétés d'un type d'entité qui sont validées par le service de données afin de déterminer si une ressource a changé. Les jetons d'accès concurrentiel, qui sont inclus dans l'en-tête eTag des demandes et des réponses du service de données, sont gérés pour vous par le client Services de données WCF . Pour plus d'informations, consultez Mise à jour du service de données (WCF Data Services).

L'objet DataServiceContext suit les modifications apportées aux objets signalées manuellement à l'aide des méthodes AddObject, UpdateObject et DeleteObject, ou à l'aide d'un objet DataServiceCollection. Lorsque la méthode SaveChanges est appelée, e client renvoie les modifications au service de données. La méthode SaveChanges peut échouer lorsque les modifications des données dans le client sont en conflit avec les modifications du service client. Lorsque cela se produit, vous devez redemander la ressource de l'entité pour recevoir les données de mise à jour. Pour supprimer les modifications du service de données, exécutez cette requête à l'aide de l'option de fusion PreserveChanges. Lorsque vous rappelez la méthodeSaveChanges, les modifications conservées sur le client sont rendues persistantes sur le service de données à condition que d'autres modifications n'aient pas déjà été apportées à la ressource dans le service de données.

Enregistrement des modifications

Les modifications sont suivies dans l'instance DataServiceContext mais ne sont pas envoyées au serveur immédiatement. Une fois que vous avez terminé d'effectuer les modifications requises pour une activité spécifiée, appelez SaveChanges afin de soumettre toutes les modifications au service de données. Un objet DataServiceResponse est retourné au terme de l'opération SaveChanges. L'objet DataServiceResponse inclut une séquence d'objets OperationResponse qui, à leur tour, contiennent une séquence d'instances EntityDescriptor ou LinkDescriptor représentant les modifications qui ont été tentées ou rendues persistantes. Lorsqu'une entité est créée ou modifiée dans le service de données, EntityDescriptor inclut une référence à l'entité mise à jour, notamment les valeurs de propriété générées par le serveur, telles que la valeur ProductID générée dans l'exemple précédent. La bibliothèque cliente met automatiquement à jour l'objet .NET Framework avec ces nouvelles valeurs.

Pour les opérations d'insertion et de mise à jour qui ont abouti, la propriété d'état de l'objet EntityDescriptor ou LinkDescriptor associé à l'opération aura la valeur Unchanged et les nouvelles valeurs seront fusionnées à l'aide de OverwriteChanges. Lorsqu'une opération d'insertion, de mise à jour ou de suppression échoue dans le service de données, l'entité conserve l'état qui était le sien avant l'appel de SaveChanges et la propriété Error de l'objet OperationResponse prend la valeur DataServiceRequestException qui contient les informations relatives à l'erreur. Pour plus d'informations, consultez Mise à jour du service de données (WCF Data Services).

Définition de la méthode HTTP pour les mises à jour

Par défaut, la bibliothèque cliente .NET Framework envoie des mises à jour aux entités existantes sous forme de demandes MERGE. Une demande MERGE met à jour les propriétés sélectionnées de l'entité ; toutefois, le client inclut systématiquement toutes les propriétés dans la demande MERGE, même celles qui n'ont pas changé. Le protocole OData prend également en charge l'envoi de demandes PUT pour mettre à jour les entités. Dans une demande PUT, une entité existante est essentiellement remplacée par une nouvelle instance de l'entité avec les valeurs de propriété du client. Pour utiliser les demandes PUT, définissez l'indicateur ReplaceOnUpdate sur l'énumération SaveChangesOptions lors de l'appel de SaveChanges.

Remarque :

Une demande PUT va se comporter différemment d'une demande MERGE lorsque le client ne connaît pas toutes les propriétés de l'entité. Cela peut se produire lors de la projection d'un type d'entité dans un nouveau type, sur le client. C'est également le cas lorsque de nouvelles propriétés ont été ajoutées à l'entité dans le modèle de données du service et la propriété IgnoreMissingProperties sur le DataServiceContext est définie sur true pour ignorer ces erreurs de mappage du client. Dans ces cas, une demande PUT va réinitialiser toutes les propriétés inconnues sur le client selon leurs valeurs par défaut.

Voir aussi

Concepts

Mise à jour du service de données (WCF Data Services)
Opérations asynchrones (WCF Data Services)
Opérations de traitement par lot (WCF Data Services)

Autres ressources

Bibliothèque cliente de WCF Data Services