Управление версиями веб-службы - добавление операций к контракту на обслуживание в WCF - PullRequest
5 голосов
/ 23 июня 2009

Что происходит в службе WCF, если я добавляю методы в качестве контрактов операций после того, как клиенты (использующие службу) завершили свои реализации? Придется ли существующим клиентам изменять свои реализации, даже если они не используют новые методы контракта операции?

РЕДАКТИРОВАТЬ: Должны ли клиенты обновлять свой прокси, даже если они не используют новые контракты?

Ответы [ 4 ]

6 голосов
/ 23 июня 2009

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

4 голосов
/ 16 февраля 2010

Я только что реализовал решение аналогичной ситуации. Первоначально я только что создал новый интерфейс, расширяющий текущий ServiceContract, используя Наследование контракта на обслуживание , обновляя определение конечной точки для доставки нового производного интерфейса (как предложено в этой статье ).

Это было хорошо для других приложений .net, которые подключались, те, кто ищет «старый» интерфейс, получили это, а те, кто ищет «новый», получили это.

Проблема заключалась в том, что у меня было приложение, отличное от .net, которое искало явно жестко привязанную привязку BasicHttpBinding_IOriginalInterface, но новый сервис предлагал BasicHttpBinding_IDerivedInterface.

Объединив оба интерфейса с общим ServiceContractName [ServiceContract(Name="IOriginalInterface")], это позволило обойти эту проблему, как рекомендовано этой статьей .

4 голосов
/ 23 июня 2009

Ответ на этот вопрос зависит от вашей точки зрения. Я говорю, что изменение договора вообще нарушает договор. Вот почему они называют их "контрактами".

Изменение контракта на обслуживание путем добавления дополнительных операций «ломает» клиента, потому что это изменит их прокси-код. Во многих корпоративных средах такое изменение требует прохода QA, даже если существующий клиентский код не вызывает новые операции. По сути, добавляя операции, вы редактируете код клиента. В этом смысле ясно, что QA требуется.

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

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

0 голосов
/ 23 июня 2009

Если вы беспокоитесь о версии, я бы советовал придерживаться подхода по контракту : именно WSDL должен быть версионным, поскольку именно WSDL вы предоставляете своим клиентам, когда они хочу использовать ваш сервис. Если WCF (или любая другая технология веб-службы в этом отношении) изменит WSDL без вашего прямого контроля, это рано или поздно вызовет у вас (или у ваших клиентов) боль.

См. WCF - первый контракт или первый код и некоторые предложения по рабочему процессу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...