2009-03-11 17 views
7

Tenía curiosidad si alguien pudiera delinear qué tipos de cambios de contrato (interfaz) de WCF en el lado del servidor romperían a un cliente que intenta enviar un mensaje, y por qué. Creo que WCF puede manejar ciertas discrepancias, pero no estoy seguro de qué puede cambiar de manera segura y qué no.Cambios en los contratos de WCF que afectan a los clientes

  • Agregar/eliminar los parámetros de un OperationContract?
  • ¿Agregar/eliminar/cambiar las propiedades serializadas de DataContract?
  • ¿Agregar/eliminar OperationContracts de un ServiceContract?

Un amigo hizo una pregunta similar aquí:

Does adding a method to a WCF ServiceContract break existing clients?

EDIT: Como John Saunders señaló, cambiando el contrato no es generalmente una buena idea, pero hay cosas construidas en que permitir Alguna tolerancia de versión (ExtensionDataObject, etc.?). Me gustaría saber qué tan flexible es la tolerancia de la versión.

Respuesta

12

Control hacia fuera este artículo sobre dasBlonde: Versioning WCF Service Contracts

En él se enumeran los cambios que se romperá clientes existentes:

  1. Retire las operaciones
  2. Cambiar nombre de la operación
  3. operación de eliminación parámetros de
  4. Añadir operación parámetros
  5. Cambiar un parámetro de operación nombre o tipo de datos
  6. Cambiar el valor de retorno de una operación de tipo
  7. cambiar el formato XML serializado de un tipo de parámetro (contrato de datos) o la operación (contrato de mensaje) utilizando explícitamente .NET atributos o código de serialización personalizado
  8. Modificar servicio formatos de codificación de operación (codificación RPC vs. Documento Literal)

This article by Michele explica con más detalle cómo puede diseñar contratos para ser más flexible. recomendaciones

+0

Gracias, eso es exactamente lo que estaba buscando –

+0

Si necesita hacer una de estas cosas, [actualice sus clientes] (http://stackoverflow.com/a/40666352/4163002). Es fácil con VS2015. – ZX9

0

Creo que la mejor práctica es pensar en contratos como irrompibles, hmmm, contratos. No los modifique una vez publicados. Es bastante fácil crear un nuevo contrato con los cambios que desea, y exponer el nuevo contrato en un nuevo punto final.

+1

Estoy de acuerdo con el concepto general de no cambiar contratos, pero si realiza pequeños cambios en un contrato, no sé si siempre es una buena idea publicar un nuevo punto final para cada nuevo contrato. Tiene alguna idea sobre esto? –

+1

Mi pensamiento es, "dales una pulgada, y tomarán una milla". No adquiera el hábito de permitir cambios "pequeños", o los hará grandes. –

4

de diseño para los contratos

  1. primera versión

    1,1. Elija con cuidado los nombres de todos los contratos (interfaces, métodos, clases y propiedades). Estos serán difíciles de cambiar en futuras versiones.

    1.2. Recuerde que no se puede cambiar la siguiente información en el futuro: número de parámetros del método, tipo de parámetros/valores de retorno/propiedades para los tipos que no están bajo su control.

  2. siguiente versión

    2,1. Si ya existe, NO cambie el espacio de nombres o el parámetro Name en ningún xxxContractAttribute.

    2.2. Si ya existe, NO cambie la propiedad Orden del DataMemberAttribute.

    2.3. Sólo se permiten cambios siguientes:

    • método Add (OperationContract) a la interfaz (ServiceContract) Método

    • Cambiar nombre en la interfaz

    • clase Renombrar (DataContract)

    • Añadir propiedad (DataMember) a clase (DataContract)

    • Renombrar propiedad en la clase

    2.4. Cualquier eliminación rompe la compatibilidad.

    2.5. Cualquier otro cambio rompe la compatibilidad.

Éstos son algunos enlaces útiles:

2

"añadir/quitar parámetros de una OperationContract "en WCF no siempre es algo que puede dañar a su cliente, pero debe saber lo que hace. En particular, agregar nuevos parámetros a un contrato de operación hará que los clientes heredados no los pasen, y en el lado del servicio se establecerán con sus valores predeterminados. Además, la eliminación de parámetros de un contrato de operación será silenciosa desde el punto de vista del cliente, y simplemente se ignorarán en el lado del servicio. Por supuesto, cambiar el nombre/tipo del parámetro hará que el cliente se rompa.

0

OK. Pregunta. Debido a la sintaxis de denominación equivocada (parámetro se especifica con mayúscula), me gustaría ajustar algo de código:

[OperationContract] 
public void Foo(string Bar){} 

a

[OperationContract] 
public void Foo(string bar){} 

Would ajustar el contrato ruptura de capital?

+2

sí, pero si solo quiere la barra en minúscula para el código, creo que puede decorar el parámetro en sí mismo con [MessageParameter (Name = "Bar")], lo que hace que se vea igual para los clientes, pero sea diferente a su servicio internamente. – Jeremy

Cuestiones relacionadas