Изменения в контракте WCF, которые влияют на клиентов - PullRequest
8 голосов
/ 11 марта 2009

Мне было бы любопытно, если бы кто-то мог обрисовать, какие типы изменений контракта (интерфейса) WCF на стороне сервера сломали бы клиент, пытающийся отправить сообщение, и почему. Я считаю, что WCF может справиться с некоторыми несоответствиями, но я не уверен, что именно вы можете изменить безопасно, а что нет.

  • Добавить / удалить параметры из OperationContract?
  • Добавить / удалить / изменить сериализованные свойства DataContract?
  • Добавить / удалить OperationContracts из ServiceContract?

Друг задал подобный вопрос здесь:

Разрывает ли добавление метода к WCF ServiceContract существующих клиентов?

РЕДАКТИРОВАТЬ: Как отметил Джон Сондерс, изменение контракта обычно не является хорошей идеей, но есть встроенные вещи, которые допускают некоторую устойчивость к версии (ExtensionDataObject и т. Д.?). Я просто хотел бы знать, насколько гибок допуск к версии.

Ответы [ 5 ]

14 голосов
/ 11 марта 2009

Ознакомьтесь с этой статьей на dasBlonde: Управление версиями сервисных контрактов WCF

В нем перечислены изменения, которые сломают существующие клиенты:

  1. Операции удаления
  2. Изменить имя операции
  3. Удалить параметры операции
  4. Добавить параметры операции
  5. Изменить имя параметра операции или тип данных
  6. Изменить тип возвращаемого значения операции
  7. Изменить сериализованный формат XML для типа параметра (контракт данных) или операции (контракт сообщения), явно используя атрибуты .NET или пользовательский код сериализации
  8. Изменение форматов кодирования операций службы (кодировка RPC по сравнению с литералом документа)

В этой статье Микеле более подробно объясняется, как можно более гибко составлять контракты.

4 голосов
/ 27 июня 2012

Рекомендации по оформлению контрактов

  1. Первая версия

    1.1. Тщательно выбирайте имена для всех контрактов (интерфейсы, методы, классы и свойства). Их будет трудно изменить в будущих версиях.

    1.2. Помните, что следующее не может быть изменено в будущем: количество параметров метода, тип параметров / возвращаемые значения / свойства для типов, не находящихся под вашим контролем.

  2. Следующая версия

    2,1. Если он уже существует, НЕ изменяйте параметр Namespace или Name в любом xxxContractAttribute.

    2,2. Если он уже существует, НЕ меняйте свойство Order в DataMemberAttribute.

    2,3. Допускаются только следующие изменения:

    • Добавление метода (OperationContract) к интерфейсу (ServiceContract)

    • Переименование метода на интерфейсе

    • Переименовать класс (DataContract)

    • Добавление свойства (DataMember) к классу (DataContract)

    • Переименовать недвижимость в класс

    2.4. Любое удаление нарушает совместимость.

    2.5. Любое другое изменение нарушает совместимость.

Вот несколько полезных ссылок:

3 голосов
/ 23 сентября 2013

«Добавить / удалить параметры из OperationContract» в WCF - это не всегда то, что может сломать вашего клиента, но вы должны знать, что вы делаете. В частности, добавление новых параметров в контракт операции приведет к тому, что устаревшие клиенты не будут передавать их, а на стороне службы им будут заданы значения по умолчанию. Более того, удаление параметров из контракта на эксплуатацию будет молчать с точки зрения клиента, и они будут просто игнорироваться на стороне службы. Конечно, изменение имени / типа параметра приведет к поломке клиента.

0 голосов
/ 16 сентября 2016

OK. Вопрос. Из-за неправильного синтаксиса именования (параметр указан заглавной буквой), я хотел бы изменить код:

[OperationContract]
public void Foo(string Bar){}

до

[OperationContract]
public void Foo(string bar){}

Будет ли корректировка контракта о прекращении капитала?

0 голосов
/ 11 марта 2009

Я думаю, что лучшая практика - считать контракты неразрывными, хммм, контракты . Не меняйте их, как только они будут опубликованы. Достаточно просто создать новый контракт с нужными вам изменениями и представить новый контракт на новой конечной точке.

...