Эффект сообщения Soap при добавлении нового участника в Data Contract - PullRequest
Новая
       6

Эффект сообщения Soap при добавлении нового участника в Data Contract

1 голос
/ 04 января 2011

Добавление новых участников в Контракт с данными безопасно для всех версий клиентов.Это известный факт.

Я хотел это проверить.

Я создал контракт с данными книги.Его первая версия имела следующие члены. 

public class Book
{
    [DataMember(IsRequired = false)]
    public long BookID;

    [DataMember(IsRequired = true)]
    public string Title;

    [DataMember(IsRequired = false)]
    public string Author;
}

Клиент был создан для этой версии Контракта.

Затем я добавил еще одного члена "Издание" в Книгу и новую версиюКнига 

public class Book
{
    [DataMember(IsRequired = false)]
    public long BookID;

    [DataMember(IsRequired = true)]
    public string Title;

    [DataMember(IsRequired = false)]
    public string Author;

    [DataMember(IsRequired = false)]
    public string Edition;
}

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

Я понимаю, что новый член "Редакция" будет принят за Nil и будет при сериализации.

Но в сообщении на стороне клиента яувидел что-то странное, следующее.

Мыльный конверт выглядит следующим образом 

  <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
  <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.8fingergenie.com/BookShop/CheckAvailability</Action>
  <ActivityId CorrelationId="631f540a-915b-4203-8fd8-e251da2fab85" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">68a15797-124d-47f7-a85a-cf5c661e8011</ActivityId>
</s:Header>
<s:Body>
  <CheckAvailability xmlns="http://www.8fingergenie.com/">
    <book xmlns:d4p1="http://8fingergenie.com" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
      <d4p1:Author>Spensor Johnson</d4p1:Author>
      <d4p1:BookID>1</d4p1:BookID>
      <d4p1:Edition i:nil="true"></d4p1:Edition>
      <d4p1:Title>Who Moved My Cheese</d4p1:Title>
    </book>
  </CheckAvailability>
</s:Body>

Мой вопрос: как клиент с более старой версией контракта Data узнал об изданииво время общения?или я что-то здесь упускаю.

Ниже приведена структура схемы Book на стороне клиента. 

  <xs:schema xmlns:tns="http://8fingergenie.com" elementFormDefault="qualified" targetNamespace="http://8fingergenie.com" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="Book">
  <xs:sequence>
    <xs:element minOccurs="0" name="Author" nillable="true" type="xs:string" />
    <xs:element minOccurs="0" name="BookID" type="xs:long" />
    <xs:element name="Title" nillable="true" type="xs:string" />
  </xs:sequence>
</xs:complexType>
<xs:element name="Book" nillable="true" type="tns:Book" />

Ответы [ 2 ]

0 голосов
/ 04 января 2011

При дальнейшем исследовании я обнаружил следующее.

Я использовал ссылку на службу в клиенте.Ссылка на службу по умолчанию создает контракт данных как тип, производный от IExtensibleDataObject.Я не заметил, что это будет по умолчанию.

Так как тип является производным от IExtensibleDataObject, новые члены с другого конца оборачиваются внутри ExtensionDataObject.Вот как клиент узнал о новом члене datacontract.

Спасибо за всех, кто пытался мне помочь.

0 голосов
/ 04 января 2011

Это не безобидно для всех клиентов. Вы могли бы написать клиента, который потерпит неудачу, если какие-либо участники были добавлены, удалены или изменены.

Тот факт, что клиент может быть преднамеренно записан для отказа в такой ситуации, подразумевает, что можно написать клиента, который непреднамеренно потерпит неудачу в той же ситуации.

...