Datendienst-Versionskontrolle (WCF Data Services)

  • Artikel

Der Open Data Protocol (OData) ermöglicht es Ihnen, Datendienste zu erstellen, damit Clients auf Daten als Ressourcen mit URIs zugreifen können, die auf einem Datenmodell basieren. OData unterstützt auch die Definition von Dienstvorgängen. Nach der ursprünglichen Bereitstellung und möglicherweise mehreren Bereitstellungen während ihrer Lebensdauer müssen diese Datendienste eventuell geändert werden. Dafür kann es verschiedene Gründe geben, z. B. veränderte Geschäftsanforderungen, Anforderungen an die Informationstechnologie oder andere Themen, die in die Dienste integriert werden müssen. Wenn Sie Änderungen an einem vorhandenen Datendienst vornehmen, müssen Sie berücksichtigen, ob eine neue Version des Datendiensts definiert wird und wie die Auswirkungen auf vorhandene Clientanwendungen am besten minimiert werden. Dieses Thema enthält einen Leitfaden, wann und wie eine neue Version eines Datendiensts erstellt wird. Es wird auch beschrieben, wie WCF Data Services einen Austausch zwischen Clients und Datendiensten behandelt, die andere Versionen des OData-Protokolls unterstützen.

Versionskontrolle eines WCF Data Service

Sobald ein Datendienst bereitgestellt wird und die Daten genutzt werden, können Änderungen am Datendienst zu Kompatibilitätsproblemen mit vorhandenen Clientanwendungen führen. Da Änderungen aber oft aufgrund der übergreifenden Geschäftsanforderungen des Diensts erforderlich sind, müssen Sie berücksichtigen, wann und wie eine neue Version des Datendiensts mit den geringsten Auswirkungen auf Clientanwendungen erstellt wird.

Datenmodelländerungen, die eine neue Version des Datendiensts empfehlen

Wenn Sie die Veröffentlichung einer neuen Version eines Datendiensts in Betracht ziehen, ist es wichtig, zu verstehen, wie die anderen Arten von Änderungen sich möglicherweise auf Clientanwendungen auswirken. Änderungen an einem Datendienst, die möglicherweise die Erstellung einer neuen Version eines Datendiensts erforderlich machen, können in die folgenden beiden Kategorien unterteilt werden:

  • Änderungen am Dienstvertrag – darunter Aktualisierungen für Dienstvorgänge, Änderungen hinsichtlich des Zugriffs auf Entitätenmengen (Feeds), Versionsänderungen und andere Änderungen bezüglich Dienstverhaltensweisen.

  • Änderungen am Datenvertrag – darunter Änderungen am Datenmodell, an Feedformaten oder Feedanpassungen.

Die folgende Tabelle führt die Arten von Änderungen auf, für die das Veröffentlichen einer neuen Version des Datendiensts in Betracht gezogen werden sollte:

Typ der Änderung

Erfordert eine neue Version

Neue Version ist nicht erforderlich

Dienstvorgänge

  • Hinzufügen von neuem Parameter

  • Ändern des Rückgabetyps

  • Entfernen des Dienstvorgangs

  • Löschen des vorhandenen Parameters

  • Hinzufügen von neuem Dienstvorgang

Dienstverhaltensweisen

  • Deaktivieren von Anzahlanforderungen

  • Deaktivieren von Projektionsunterstützung

  • Erhöhen der erforderlichen Datendienstversion

  • Aktivieren von Anzahlanforderungen

  • Aktivieren von Projektionsunterstützung

  • Verringern der erforderlichen Datendienstversion

Entitätenmengenberechtigungen

  • Einschränken von Entitätenmengenberechtigungen

  • Ändern des Antwortcodes (neuer erster Ziffernwert) 1

  • Lockern von Entitätenmengenberechtigungen

  • Ändern des Antwortcodes (gleicher erster Ziffernwert)

Entitätseigenschaften

  • Entfernen von vorhandener Eigenschaft oder Beziehung

  • Hinzufügen von Eigenschaft, die keine Null-Werte zulässt

  • Ändern von vorhandener Eigenschaft

  • Hinzufügen von Eigenschaft, die Null-Werte zulässt2

Entitätenmengen

  • Entfernen von Entitätenmenge

  • Hinzufügen von abgeleitetem Typ

  • Ändern von Basistyp

  • Hinzufügen von Entitätenmenge

Feedanpassung

  • Ändern von Entitätseigenschaftszuordnung

1 Dies hängt möglicherweise davon ab, wie stark eine Clientanwendung auf den Empfang eines bestimmten Fehlercodes basiert.

2 Sie können die IgnoreMissingProperties-Eigenschaft auf true festlegen, sodass der Client alle neuen Eigenschaften ignoriert, die vom Datendienst gesendet werden und nicht im Client definiert werden. Wenn aber Einfügungen vorgenommen werden, werden die nicht vom Client einbezogenen Eigenschaften in der POST-Anforderung auf ihre Standardwerte festgelegt. Bei Updates können vorhandene Daten in einer Eigenschaft, die dem Client nicht bekannt ist, mit Standardwerten überschrieben werden. In diesem Fall sollten Sie das Update als MERGE-Anforderung senden, die der Standard ist. Weitere Informationen finden Sie unter Verwalten des Datendienstkontextes (WCF Data Services).

So versionieren Sie einen Datendienst

Bei Bedarf wird eine neue Datendienstversion definiert, indem eine neue Instanz des Diensts mit einem aktualisierten Dienstvertrag oder einem Datenmodell erstellt wird. Dieser neue Dienst wird dann mit einem neuen URI-Endpunkt verfügbar gemacht, der sich von der früheren Version unterscheidet. So gilt z. B. Folgendes:

Wenn Sie einen Datendienst aktualisieren, müssen Clients auch auf Grundlage der neuen Datendienstmetadaten aktualisiert werden und den neuen Stamm-URI verwenden. Wenn möglich, sollten Sie die frühere Version des Datendiensts beibehalten, um Clients zu unterstützen, die noch nicht für die Verwendung der neuen Version aktualisiert wurden. Frühere Versionen eines Datendiensts können entfernt werden, wenn sie nicht mehr benötigt werden. Sie sollten erwägen, den Datendienstendpunkt-URI in einer externen Konfigurationsdatei beizubehalten.

OData-Protokollversionen

Wenn neue Versionen von OData veröffentlicht werden, verwenden Clientanwendungen möglicherweise nicht die Version des OData-Protokolls, die vom Datendienst unterstützt wird. Eine ältere Clientanwendung greift möglicherweise auf einen Datendienst zu, der eine neuere Version von OData unterstützt. Eine Clientanwendung kann möglicherweise auch eine neuere Version der OData-Clientbibliothek verwenden, die eine neuere Version von WCF Data Services unterstützt als der Datendienst, auf den zugegriffen wird.

WCF Data Services nutzt die von OData bereitgestellte Unterstützung zur Behandlung solcher Versionsszenarien. Zudem wird das Generieren und Erstellen von Clientdatendienstklassen mithilfe von Datenmodellmetadaten auch dann unterstützt, wenn der Client eine andere Version von OData verwendet als der Datendienst. Weitere Informationen finden Sie unter OData: Protocol Versioning.

Versionsaushandlung

Der Datendienst kann so konfiguriert werden, dass die höchste Version des OData-Protokolls definiert wird, die unabhängig von der vom Client angeforderten Version vom Dienst verwendet wird. Hierzu geben Sie einen DataServiceProtocolVersion-Wert für die MaxProtocolVersion-Eigenschaft der vom Datendienst verwendeten DataServiceBehavior-Instanz an. Weitere Informationen finden Sie unter Konfigurieren des Datendiensts (WCF Data Services).

Wenn eine Anwendung mithilfe der WCF Data Services-Clientbibliotheken auf einen Datendienst zugreift, legen die Bibliotheken diese Header je nach OData-Version und den in der Anwendung verwendeten Funktionen automatisch auf die richtigen Werte fest. In der Standardeinstellung verwendet WCF Data Services die niedrigste Protokollversion, die den angeforderten Vorgang unterstützt.

Die folgende Tabelle enthält die Versionen von .NET Framework und Silverlight, die WCF Data Services-Unterstützung für bestimmte Versionen des OData-Protokolls bieten.

OData-Protokollversion

Unterstützt seit...

Version 1

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

  • Silverlight Version 3

Version 2

  • .NET Framework Version 4

  • Update auf .NET Framework Version 3.5 SP1. Sie können das Update vom Microsoft Download Center herunterladen und anschließend installieren.

  • Silverlight Version 4

Version 3

  • Sie können eine Vorabversion, die OData Version 3 unterstützt, vom Microsoft Download Center herunterladen und installieren.

Metadatenversionen

Standardmäßig verwendet WCF Data Services Version 1.1 von CSDL, um ein Datenmodell darzustellen. Dies ist immer bei Datenmodellen der Fall, die auf einem Reflektionsanbieter oder einem benutzerdefinierten Datendienstanbieter basieren. Wenn das Datenmodell jedoch mit Entity Framework definiert wird, wird die CSDL-Version zurückgegeben, die von Entity Framework verwendet wird. Die CSDL-Version wird anhand des Namespace des Schemaelements bestimmt. Weitere Informationen finden Sie unter in der Spezifikation [MC-CSDL]: Conceptual Schema Definition File Format.

Das DataServices-Element der zurückgegebenen Metadaten enthält auch ein DataServiceVersion-Attribut, das den gleichen Wert wie der DataServiceVersion-Header in der Antwortnachricht hat. Clientanwendungen wie das Dialogfeld Dienstverweis hinzufügen in Visual Studio generieren mithilfe dieser Informationen Client-Datendienstklassen, die korrekt mit der Version von WCF Data Services funktionieren, die den Datendienst hostet. Weitere Informationen finden Sie unter OData: Protocol Versioning.

Siehe auch

Konzepte

Datendienstanbieter (WCF Data Services)

Andere Ressourcen

Datendienst (WCF Data Services)