Управление версиями веб-сервиса - добавляющие операции к контракту на обслуживание в WCF

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

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

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

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

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

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

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

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

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

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

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