Datendienst-Versionskontrolle (WCF Data Services)
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 |
|
|
Dienstverhaltensweisen |
|
|
Entitätenmengenberechtigungen |
|
|
Entitätseigenschaften |
|
|
Entitätenmengen |
|
|
Feedanpassung |
|
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:
Alte Version: http://services.odata.org/Northwind/v1/Northwind.svc/
Neue Version: http://services.odata.org/Northwind/v2/Northwind.svc/
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 |
|
Version 2 |
|
Version 3 |
|
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)