Compartir a través de


Contratos de datos compatibles con el reenvío

Una característica del sistema de contrato de datos de Windows Communication Foundation (WCF) es que los contratos pueden evolucionar con el tiempo sin interrupciones. Es decir, un cliente con una versión anterior de un contrato de datos puede comunicarse con un servicio con una versión más reciente del mismo contrato de datos, o un cliente con una versión más reciente de un contrato de datos puede comunicarse con una versión anterior del mismo contrato de datos. Para obtener más información, consulte Procedimientos recomendados: Control de versiones del contrato de datos.

Puede aplicar la mayoría de las características del control de versiones en la medida que se necesite cuando se crean las nuevas versiones de un contrato del dato existente. Sin embargo, una característica del control de versiones, round-tripping (recorrido de ida y vuelta), debe estar integrada en el tipo de la primera versión para que funcione correctamente.

Round-Tripping (recorrido de ida y vuelta)

Round-tripping tiene lugar cuando los datos pasan de una nueva versión a una versión anterior y de vuelta a la nueva versión de un contrato de datos. El round-tripping garantiza que no se pierdan datos. Habilitar el round-tripping hace que el tipo sea compatible por adelantado con cualquier cambio futuro admitido por el modelo de control de versiones del contrato de datos.

Para habilitar el round-tripping para un tipo determinado, el tipo debe implementar la interfaz IExtensibleDataObject. La interfaz contiene una propiedad, ExtensionData (que devuelve el tipo ExtensionDataObject ). La propiedad almacena cualquier dato de las versiones futuras del contrato de datos que es desconocido para la versión actual.

Ejemplo

El siguiente contrato de datos no compatible por adelantado con los cambios futuros.

[DataContract]
public class Person
{
    [DataMember]
    public string fullName;
}
<DataContract()> _
Public Class Person
    <DataMember()> _
    Public fullName As String
End Class

Para hacer que el tipo sea compatible con los cambios futuros (como agregar un nuevo miembro de datos denominado "phoneNumber"), implemente la interfaz IExtensibleDataObject.

[DataContract]
public class Person : IExtensibleDataObject
{
    [DataMember]
    public string fullName;
    private ExtensionDataObject theData;

    public virtual ExtensionDataObject ExtensionData
    {
        get { return theData; }
        set { theData = value; }
    }
}
<DataContract()> _
Public Class Person
    Implements IExtensibleDataObject
    <DataMember()> _
    Public fullName As String
    Private theData As ExtensionDataObject


    Public Overridable Property ExtensionData() As _
     ExtensionDataObject Implements _
     IExtensibleDataObject.ExtensionData
        Get
            Return theData
        End Get
        Set
            theData = value
        End Set
    End Property
End Class

Cuando la infraestructura WCF encuentra datos que no forman parte del contrato de datos original, los datos se almacenan en la propiedad y se conservan. No se procesa para nada más, salvo para el almacenamiento temporal. Si el objeto se devuelve a donde se originó, se devuelven también los datos originales (desconocidos). Por consiguiente, los datos han realizado un viaje de ida y vuelta (round trip) hasta y desde el extremo de origen sin sufrir pérdidas. Tenga en cuenta, sin embargo, que si el punto de conexión de origen exigiera que se procesasen los datos, la expectativa no se cumple, y el punto de conexión debe detectar y adaptar el cambio de algún modo.

El tipo ExtensionDataObject no contiene ningún método público ni propiedades. Por tanto, es imposible obtener acceso directo a los datos almacenados dentro de la propiedad ExtensionData.

La característica de round-tripping puede desactivarse, estableciendo ignoreExtensionDataObject en true en el constructor DataContractSerializer o estableciendo la propiedad IgnoreExtensionDataObject en true en el ServiceBehaviorAttribute. Cuando esta característica está deshabilitada, el deserializador no rellenará la propiedad ExtensionData y el serializador no emitirá el contenido de la propiedad.

Consulte también