Versiones de servicios web - Agregar operaciones a un contrato de servicio en WCF

Question

En un servicio WCF, ¿qué sucede si agrego métodos como contratos de operación después de que los clientes (que consumen el servicio) hayan completado sus implementaciones? ¿Tendrán los clientes existentes que modificar sus implementaciones aunque no utilicen los nuevos métodos de contrato de operación?

EDITAR: ¿Los clientes tendrán que actualizar su proxy aunque no utilicen los nuevos contratos?

Answer 1

No, los nuevos contratos de operación en el servicio no romperán la interfaz del cliente. Puede cambiar libremente su interfaz siempre que las firmas de métodos de las que depende el cliente permanezcan indemnes. Esto significa que puede agregar tantos nuevos miembros de interfaz como desee.

Answer 2

La respuesta depende de su punto de vista. Digo que cambiar el contrato viola el contrato. Es por eso que los llaman "contratos".

Cambiar el contrato de servicio agregando operaciones adicionales "rompe" el cliente porque cambiará su código de proxy. En muchos entornos empresariales, dicho cambio requiere un pase de control de calidad, incluso si el código de cliente existente no llama a las nuevas operaciones. Básicamente, al agregar operaciones, está editando el código del cliente. En ese sentido, está claro que se requiere QA.

No es necesario modificar el contrato de servicio, cuando en su lugar puede crear un nuevo contrato de servicio y tener un punto final de servicio diferente para implementarlo. Incluso puede hacer que el nuevo servicio implemente tanto los contratos antiguos como los nuevos y compartir exactamente el mismo código para implementar el anterior.

También soy uno de los tipos pasados ​​de moda que creen que debería usar un espacio de nombres diferente para un contrato diferente. En al menos un sentido delicado, los contratos viejos y nuevos son diferentes, por lo que potencialmente el mismo nombre podría significar cosas diferentes entre los dos. Esto puede mitigarse haciendo que el nuevo contrato se derive del anterior, de modo que los nombres antiguos permanezcan en el antiguo espacio de nombres, aunque aparecerán nuevos nombres en el nuevo espacio de nombres.

Answer 3

Si le preocupa el control de versiones, mi consejo sería seguir primer contrato enfoque: WSDL debe ser el que se va a versionar, ya que es WSDL que está exponiendo a sus clientes cuando quieren usar tu servicio. Dejar WCDL para ser cambiado por WCF (o cualquier otra tecnología de servicio web para ese asunto) sin su control directo tarde o temprano causará dolor a usted (o a sus clientes).

Consulte WCF - contract-first vs. code-first y algunas sugerencias sobre el flujo de trabajo.

Answer 4

Acabo de implementar una solución a una situación similar. Inicialmente, acabo de crear una nueva interfaz que amplía el ServiceContract actual, utilizando Contrato de servicios de herencia, actualizando la definición del punto final para entregar la nueva interfaz derivada (como se sugiere in this article).

Esto estaba bien para otras aplicaciones de .net que se conectaban, aquellos que buscaban la 'vieja' interfaz obtenían eso y aquellos que buscaban lo 'nuevo' obtenían esa en su lugar.

El problema era que tenía una aplicación no .NET que buscaba un enlace explícitamente codificado, BasicHttpBinding_IOriginalInterface, pero el nuevo servicio ofrecía BasicHttpBinding_IDerivedInterface.

Al unificar ambas interfaces de con un ServiceContractName común [ServiceContract(Name="IOriginalInterface")], esto tiene alrededor de ese tema, según lo recomendado por this article.