Web Versioning Servizio - Aggiunta di operazioni per un contratto di servizio in WCF

Question

In un servizio WCF, che cosa succede se aggiungo metodi come contratti di gestione, dopo i clienti (che consumano il servizio) hanno completato le loro implementazioni? I clienti esistenti dovranno modificare le loro implementazioni anche se non usano i nuovi metodi del contratto operativo?

MODIFICA: i client devono aggiornare il proxy anche se non utilizzano i nuovi contratti?

Answer 1

No, i nuovi contratti operativi nel servizio non interromperanno l'interfaccia del client. Puoi cambiare liberamente la tua interfaccia se le firme dei metodi su cui fa affidamento il cliente rimangono indenni. Ciò significa che puoi aggiungere quanti nuovi membri dell'interfaccia desideri.

Answer 2

La risposta a questo dipende dal vostro punto di vista. Dico che cambiare il contratto viola il contratto. Ecco perché li chiamano "contratti".

Modifica del contratto di servizio con l'aggiunta di ulteriori operazioni "rompe" il cliente perché cambierà il loro codice proxy. In molti ambienti aziendali, tale modifica richiede un passaggio QA, anche se il codice client esistente non sta chiamando le nuove operazioni. Fondamentalmente, aggiungendo operazioni, stai modificando il codice cliente. In questo senso, è chiaro che è necessario il QA.

Non c'è bisogno di modificare il contratto di servizio, quando si può invece creare un nuovo contratto di servizio, e hanno un diverso endpoint del servizio implementarlo. Puoi anche fare in modo che il nuovo servizio implementa sia i vecchi che i nuovi contratti e condivida lo stesso codice per implementare quello vecchio con.

Sono anche uno dei vecchi tipi stile che credono è necessario utilizzare uno spazio dei nomi diverso per un contratto diverso. In un senso almeno pignolo, i vecchi e nuovi contratti sono diversi, quindi potenzialmente lo stesso nome potrebbe significare cose diverse tra i due. Questo può essere mitigato facendo in modo che il nuovo contratto derivi dal vecchio, in modo che i vecchi nomi rimangano nel vecchio spazio dei nomi, mentre i nuovi nomi si troverebbero nel nuovo spazio dei nomi.

Answer 3

Se siete preoccupati per il controllo delle versioni, il mio consiglio è di seguire contratto a primo approccio: WSDL dovrebbe essere quello di essere di versione, dal momento che è WSDL che si sta esponendo ai vostri clienti quando vogliono usare il tuo servizio. Lasciare che WSDL sia modificato da WCF (o da qualsiasi altra tecnologia di servizi Web) senza il tuo controllo diretto prima o poi causerà dolore a te (o ai tuoi clienti).

Vedi WCF - contract-first vs. code-first e alcuni suggerimenti sul flusso di lavoro.

Answer 4

Ho appena implementato una soluzione per una situazione simile. Inizialmente ho appena creato una nuova interfaccia per estendere il ServiceContract corrente, utilizzando l'Ereditarietà del contratto di servizio , aggiornando la definizione dell'endpoint per fornire la nuova interfaccia derivata (come suggerito in this article).

questo andava bene per altre applicazioni .NET che sono state connettono, chi cerca l'interfaccia 'vecchio' ottenuto che e coloro che cercano la 'nuova' ottenuto che uno invece.

Il problema era che avevo un'app non .net che cercava un binding esplicitamente codificato, BasicHttpBinding_IOriginalInterface, ma il nuovo servizio offriva BasicHttpBinding_IDerivedInterface.

Unificando entrambi interfacce con una ServiceContractName comuni [ServiceContract(Name="IOriginalInterface")], questo ha intorno a quel problema, come raccomandato da this article.