c# - servicecontract - wcf programming

WCF: MessageContract, DataContract... ¿Confundido?

Question

Estoy escribiendo mi primer servicio WCF. Decidí escribir el servicio como una DLL para comenzar y luego ver las cosas de WCF después, que es donde estoy ahora.

El arquitecto me informó que debía mantener un formato específico para los objetos de mensaje que he hecho. Sin embargo, he utilizado interfaces, tipos complejos y listas de los mismos en mis objetos de mensaje. Voy a agregar los atributos y me estoy confundiendo un poco.

Aquí hay un ejemplo de muestra de mi código.

[ServiceContract]
public interface MyServiceContract
{
     [OperationContract]
     MyMethodResponseMessage MyMethod(MyMethodRequestMessage request);
}

public class MyService : MyServiceContract
{
    public MyMethodResponseMessage MyMethod(MyMethodRequestMessage request)
    {
        //Do things
    }
}

//Messages
[MessageContract]
public class MyMethodResponseMessage 
{
    [MessageBodyMember]
    public MyMethodResponse Body { get; set; }
}

[DataContract]
public class MyMethodResponse
{
    [DataMember]
    public IMyComplexTypeItem { get; set; }

    [DataMember]
    public List<IMyComplexType> Items { get; set; }

    [DataMember]
    public bool Success { get; set; }
}

//DTO    
public interface IMyComplexType 
{
    [DataMember]
    string Identity { get; set; }
}

[DataContract]
public class MyComplexType1 : IMyComplexType
{
     [DataMember]
     public virtual string Identity
}

¿Alguien puede comentar sobre la corrección en el uso de MessageContract, DataContract, DataMember y Serializable, etc.? ¿Alguna sugerencia o errores evidentes?

¿Qué serializador es el mejor para usar? y ¿cuál es la mejor estrategia para garantizar que obtenga un XML bien formado a partir de esto para que otros clientes puedan consumir mi servicio fácilmente?

Answer 1

Aunque no es una respuesta directa a su pregunta, vale la pena tomar nota de lo siguiente de MSDN-Uso de contratos de mensajes

Cada encabezado de mensaje individual y parte de cuerpo de mensaje se serializa (se convierte en XML) utilizando el motor de serialización elegido para el contrato de servicio donde se utiliza el mensaje. El motor de serialización predeterminado, XmlFormatter , puede manejar cualquier tipo que tenga un contrato de datos , ya sea de forma explícita (mediante System. Runtime. Serialization. DataContractAttribute) o implícitamente (por ser un tipo primitivo, tener System.SerializableAttribute, etc. )

Answer 2

Con respecto a la solicitud / respuesta, un [DataContract] funcionaría igual de bien. Una de las ventajas de los contratos de mensajes es que puede establecer privacidad contra los miembros, pero en muchos casos esto no es necesario. En tales casos, prefiero mantener el contrato lo más simple posible, solo como un contrato de datos.

Re que serializador - eso es en gran medida un factor de la configuración. Por defecto sobre http, por ejemplo, será DataContractSerializer .

Sin embargo, no estoy seguro de que la lista de IMyComplexType vaya a funcionar muy bien. Podrías intentarlo, pero generalmente quiere tipos concretos. Tenga en cuenta que con las clases base puede usar [KnownType] para especificar los subtipos permitidos.

Tenga en cuenta que a diferencia de XmlSerializer , no es un requisito para los miembros de la colección tener instaladores, aunque es posible que necesite agregar un método de devolución de llamada OnDeserializing para inicializar la lista si lo hace (WCF no llama a los constructores).

Aparte: también puede usar protobuf-net con contratos de datos y WCF (siempre que tengan un pedido explícito); esto es más densamente empaquetado que el xml regular. Sin embargo, no tiene soporte para los contratos de mensajes en este momento.