WCF: MessageContract, DataContract... Confused?

Я пишу свой первый сервис WCF. Я решил написать сервис так же, как и DLL для начала, а затем аспект содержимого WCF потом, где я сейчас.

Мне советовал архитектор, что я должен придерживаться определенного формата для объектов сообщений, которые я сделал. Однако я использовал интерфейсы, сложные типы и списки в моих объектах сообщений. Я прихожу к добавлению атрибутов, и я немного запутался.

Здесь показан пример моего кода.

[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
}

Можно ли прокомментировать правильность использования MessageContract, DataContract, DataMember и Serializable и т.д.? Любые указатели или вопиющие ошибки?

И какой сериализатор лучше всего использовать? и какова лучшая стратегия для обеспечения того, чтобы я получал хорошо сформированный XML из этого, чтобы другие клиенты могли легко использовать мой сервис?

Ответы

Ответ 1

Re запрос/ответ - a [DataContract] будет работать так же хорошо. Одним из преимуществ сообщений-контрактов является то, что вы можете установить конфиденциальность в отношении членов, но во многих случаях это необязательно. В таких случаях я предпочитаю максимально упростить договор, как контракт с данными.

Re, какой сериализатор - это в значительной степени фактор конфигурации. Например, по умолчанию для http это будет DataContractSerializer.

Я не уверен, однако, что список IMyComplexType будет работать очень хорошо. Вы можете попробовать, но в целом он хочет конкретных типов. Обратите внимание, что с базовыми классами вы можете использовать [KnownType] для указания разрешенных подтипов.

Обратите внимание, что в отличие от XmlSerializer для членов коллекции не требуется устанавливать сеттеры - хотя вам может понадобиться добавить метод обратного вызова OnDeserializing для инициализации списка, если вы это сделаете (WCF не вызывает конструкторы).

Кроме того, вы также можете использовать protobuf-net с данными-контрактами и WCF (при условии, что они имеют явный порядок); это более плотная упаковка, чем обычный xml. Тем не менее, у него нет поддержки сообщений-контрактов.

Ответ 2

Хотя не прямой ответ на ваш вопрос, стоит обратить внимание на следующее из MSDN -Using Message Contracts

Каждый отдельный заголовок сообщения и часть тела сообщения сериализуются (превращаются в XML), используя выбранный механизм сериализации для контракта на обслуживание, в котором используется сообщение. Механизм сериализации по умолчанию, XmlFormatter, может обрабатывать любой тип с контрактом данных, либо явно (с использованием времени выполнения системы.) Сериализация DataContractAttribute) или неявно (будучи примитивным типом, имеющим атрибут System.SerializableAttribute и т.д.).