Partager via

Contrôle de version d'un service de données (WCF Data Services)

  • Article

Protocole OData (Open Data) vous permet de créer des services de données afin que les clients puissent accéder aux données en tant que ressources à l'aide des URI basés sur un modèle de données. OData prend également en charge la définition des opérations de service. Après leur déploiement initial, et potentiellement plusieurs fois pendant leur durée de vie, il peut s'avérer nécessaire de modifier ces services de données (et les points de terminaison qu'ils exposent) pour diverses raisons, telles que l'évolution des besoins de l'entreprise, des spécifications informatiques, ou pour résoudre d'autres problèmes. Lorsque vous apportez des modifications à un service de données existant, vous devez choisir de définir une nouvelle version de votre service de données et comment mieux réduire l'impact sur les applications clientes existantes. Cette rubrique fournit des conseils sur le moment et la façon de créer une nouvelle version d'un service de données. Elle décrit aussi comment Services de données WCF gère l'échange entre les clients et les services de données qui prennent en charge différentes versions du protocole OData .

Contrôle de version d'un service de données WCF

Lorsqu'un service de données est déployé et que les données sont en cours de consommation, le service de données peut provoquer des problèmes de compatibilité avec les applications clientes existantes. Toutefois, étant donné que les modifications sont souvent requises par les exigences opérationnelles globales du service, vous devez déterminer quand et comment créer une nouvelle version de votre service de données avec le moins d'impact possible sur les applications clientes.

Modifications du modèle de données qui recommandent une nouvelle version de service de données

Au moment de choisir de publier ou non une nouvelle version d'un service de données, il est important de comprendre comment les différents types de modifications peuvent affecter les applications clientes. Les modifications apportées à un service de données pouvant nécessiter la création d'une nouvelle version de service de données, appartiennent aux deux catégories suivantes :

  • Modifications apportées au contrat de service, incluant les mises à jour des opérations de service, les modifications de l'accessibilité des jeux d'entités (flux), les modifications de version et d'autres modifications apportées aux comportements de service.

  • Modifications apportées au contrat de données, incluant les modifications apportées au modèle de données, aux formats de flux ou aux personnalisations de flux.

Le tableau suivant contient les types de modifications pour lesquelles vous devez envisager de publier une nouvelle version du service de données :

Type de changement.

Requiert une nouvelle version

Nouvelle version inutile

Opérations de service

  • Ajout d'un nouveau paramètre

  • Modifier le type de retour

  • Supprimer l'opération de service

  • Paramètre de suppression existant

  • Ajout d'une nouvelle opération de service

Comportements du service

  • Désactiver les demandes de nombre

  • Désactiver la prise en charge de projection

  • Augmentez la version du service de données requise

  • Activer les demandes de nombre

  • Désactiver la prise en charge de projection

  • Utiliser la version de service de données requise inférieure

Autorisations du jeu d'entités

  • Limite les autorisations du jeu d'entités

  • Modifier le code de réponse (la nouvelle première valeur de chiffres) 1

  • Relâcher les autorisations du jeu d'entités

  • Modifier le code de réponse (la même première valeur de chiffres)

Propriétés d'entité

  • Supprimer la propriété ou relation existante

  • Ajout de la propriété non-nullable

  • Modifier la propriété existante

  • Ajout de la propriété nullable2

Jeux d'entités

  • Supprimer le jeu d'entités

  • Ajout d'un type dérivé

  • Modifier le type de base

  • Ajout d'un jeu d'entités

Personnalisation de flux

  • Modifier le mappage de propriété d'entité

1 Cela peut dépendre de la façon dont une application cliente repose strictement sur la réception d'un code d'erreur spécifique.

2 Vous pouvez définir la propriété IgnoreMissingProperties sur true pour que le client ignore toutes les nouvelles propriétés envoyées par le service de données qui ne sont pas définies sur le client. Toutefois, lorsque des insertions sont réalisées, les propriétés non incluses par le client dans la demande POST sont définies sur leurs valeurs par défaut. Pour les mises à jour, toutes les données existantes dans une propriété inconnue du client peuvent être remplacées par les valeurs par défaut. Dans ce cas, vous devez envoyer la mise à jour sous la forme d'une demande MERGE, qui est la valeur par défaut. Pour plus d'informations, consultez Gérer le contexte du service de données (WCF Data Services).

Procédure de versionnage d'un service de données

Si nécessaire, une nouvelle version de service de données est définie en créant une nouvelle instance du service avec un contrat de service ou un modèle de données mis à jour. Ce nouveau service est alors exposé à l'aide d'un nouveau point de terminaison d'URI, qui le distingue de la version antérieure. Par exemple :

Lors de la mise à niveau d'un service de données, les clients doivent également être mis à jour en fonction des nouvelles métadonnées de service de données et utiliser le nouveau URI racine. Si possible, vous devez maintenir la version antérieure du service de données pour prendre en charge les clients qui n'ont pas encore été mis à niveau pour utiliser la nouvelle version. Les versions antérieures d'un service de données peuvent être supprimées lorsqu'elles sont devenues inutiles. Vous devez envisager de conserver l'URI de point de terminaison de service de données dans un fichier de configuration externe.

Versions du protocole OData

Alors que de nouvelles versions de OData sont publiées, il se peut que les applications clientes n'utilisent pas la même version du protocole OData que celle prise en charge par le service de données. Une application cliente plus ancienne peut accéder à un service de données qui prend en charge une version plus récente de OData. Une application cliente peut également utiliser une version plus récente de la bibliothèque cliente de Services de données WCF, qui prend en charge une version plus récente de OData par rapport au service de données qui est accédé.

Services de données WCF utilise le support fourni par OData pour gérer ces scénarios de versionnage. Il y a également une prise en charge pour générer et utiliser des métadonnées de modèle de données pour créer des classes de service de données client lorsque le client utilise une version OData différente de celle utilisée par le service de données. Pour plus d'informations, consultez OData: Protocol Versioning (en anglais).

Négociation de version

Le service de données peut être configuré pour définir la version la plus récente du protocole OData qui sera utilisée par le service, quelle que soit la version demandée par le client. Vous pouvez procéder en spécifiant une valeur DataServiceProtocolVersion pour la propriété MaxProtocolVersion du DataServiceBehavior utilisé par le service de données. Pour plus d'informations, consultez Configuration du service de données (WCF Data Services).

Lorsqu'une application utilise les bibliothèques clientes Services de données WCF pour accéder à un service de données, les bibliothèques définissent automatiquement ces en-têtes pour qu'ils aient les valeurs correctes, en fonction de la version d'OData et des fonctionnalités utilisées pour votre application. Par défaut, Services de données WCF utilise la version de protocole la plus basse prenant en charge l'opération demandée.

Le tableau suivant fournit des détails sur les versions de .NET Framework et Silverlight qui incluent la prise en charge Services de données WCF des versions spécifiques du protocole OData.

Version de protocole OData

Prise en charge depuis...

Version 1

  • .NET Framework version 3.5 Service Pack 1 (SP1)

  • Silverlight version 3

Version 2

  • .NET Framework version 4

  • Mise à jour vers .NET Framework version 3.5 SP1. Vous pouvez télécharger et installer la mise à jour à partir du Centre de téléchargement Microsoft.

  • Silverlight version 4

Version 3

Versions de métadonnées

Par défaut, Services de données WCF utilise la version 1.1 de CSDL pour représenter un modèle de données. C'est toujours le cas pour les modèles de données basés sur un fournisseur de réflexion ou un fournisseur de services de données personnalisé. Toutefois, lorsque le modèle de données est défini à l'aide d'Entity Framework, la version de CSDL retournée est la même que celle utilisée par l'Entity Framework. La version de CSDL est déterminée par l'espace de noms de l'élément de schéma. Pour plus d'informations, consultez sur la spécification [MC-CSDL] : Format des fichiers de définition de schéma conceptuel.

L'élément DataServices des métadonnées retournées contient également un attribut DataServiceVersion, qui est la même valeur que l'en-tête DataServiceVersion du message de réponse. Les applications clientes, telles que la boîte de dialogue Ajouter une référence de service dans Visual Studio, utilisent ces informations pour générer des classes de service de données clientes qui fonctionnent correctement avec la version de Services de données WCF qui héberge le service de données. Pour plus d'informations, consultez OData: Protocol Versioning (en anglais).

Voir aussi

Concepts

Fournisseurs de services de données (WCF Data Services)

Autres ressources

Services de données (WCF Data Services)