WCF: MessageContract, DataContract ... В замешательстве?

Question

Я пишу свой первый сервис 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, чтобы другие клиенты могли легко использовать мой сервис?

Answer 1

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

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

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

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

В сторону: вы также можете использовать protobuf-net с контрактами данных и WCF (при условии, что у них есть явный Заказ); это более плотно упаковано, чем обычный XML. В настоящее время он не поддерживает контракты на сообщения.

Answer 2

Хотя это и не прямой ответ на ваш вопрос, стоит обратить внимание на следующее из MSDN -Использование сообщений о контрактах

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