Изменения контракта WCF, влияющие на клиентов

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

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

Друг задал здесь похожий вопрос:

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

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


wcf datacontract operationcontract servicecontract
person Andy White    schedule 11.03.2009    source источник

Ответы (5)


arrow_upward
16
arrow_downward

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

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

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

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

person Jonathan Parker    schedule 11.03.2009
comment
Спасибо, это именно то, что я искал - person Andy White; 11.03.2009
comment
Если вам нужно сделать одно из этих действий, обновите клиентов. С VS2015 это просто. - person ZX9; 18.11.2016
comment
Будет ли создание свойства контракта Guid, не допускающего значения NULL, как Nullable, нарушит работу клиентов? - person Jurijs Kastanovs; 22.06.2018
comment
как насчет пространств имен? изменение пространства имен нарушает контракт? В конце концов, он будет сериализован так же - person Li3ro; 05.05.2020

arrow_upward
4
arrow_downward

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

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

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

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

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

    2.1. Если он уже существует, НЕ изменяйте пространство имен или параметр имени для любого атрибута xxxContractAttribute.

    2.2. Если он уже существует, НЕ изменяйте свойство Order атрибута DataMemberAttribute.

    2.3. Разрешены только следующие изменения:

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

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

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

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

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

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

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

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

person k0stya    schedule 27.06.2012

arrow_upward
3
arrow_downward

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

person Daniele Giallonardo    schedule 23.09.2013

arrow_upward
1
arrow_downward

В ПОРЯДКЕ. Вопрос. Из-за неправильного синтаксиса именования (параметр указывается с заглавной буквы) я хотел бы скорректировать код:

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

to

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

Будет ли корректировка договора о перерыве в капитале?

person Samjongenelen    schedule 16.09.2016
comment
да, но если вам просто нужна строчная строка для целей кода, я думаю, вы можете украсить сам параметр [MessageParameter (Name = Bar)], чтобы он выглядел одинаково для клиентов, но отличался от вашей службы внутри. - person Jeremy; 02.12.2016

arrow_upward
0
arrow_downward

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

person John Saunders    schedule 11.03.2009
comment
Я согласен с общей концепцией не изменять контракты, но если вы вносите небольшие изменения в контракт, я не знаю, всегда ли будет хорошей идеей публиковать новую конечную точку для каждого нового контракта. Есть мысли по этому поводу? - person Andy White; 18.03.2009
comment
Я думаю: дайте им дюйм, и они пройдут милю. Не входите в привычку допускать небольшие изменения, иначе они внесут большие. - person John Saunders; 18.03.2009