WCF - управление версиями

Если мне нужно отказаться от этого контракта на обслуживание:

[ServiceContract(Namespace="http://api.x.com/Svc1")]
public interface IService1
{
   [OperationContract(Name = "AddCustomer")]
   bool AddCustomer(DTOCustomer1 customer);
}

к этому:

[ServiceContract(Namespace="http://api.x.com/Svc1")]
public interface IService1
{
   [OperationContract(Name = "AddCustomer")]
   bool AddCustomer(DTOCustomer2 customer);
}

и согласно этой хорошей статье: Управление версиями WCF Я понимаю, что при изменении контракта данных необходимо определить новый контракт vs контракта данных в новом пространстве имен с последующим определением нового контракта vs контракта службы в новом пространстве имен, после чего должна быть добавлена ​​новая конечная точка. .

Как именно я должен это сделать? Есть где-нибудь пример? Не могли бы вы написать что-нибудь на основе моего контракта на обслуживание, показанного выше?

Заранее спасибо!


versioning namespaces wcf contracts
person Learner    schedule 10.01.2012    source источник
comment
Возможно, вы также можете подумать об управлении версиями WCF, включив в URL-ссылку служб номер версии. А в проекте WCF Services вы также можете использовать разные папки для каждой версии.   -  person DmitryBoyko    schedule 10.01.2012
comment
@ Дмитрий: Мне это интересно. Не могли бы вы указать мне на какие-либо ссылки, связанные с этим? Спасибо   -  person Learner    schedule 11.01.2012
comment
Не помню, где я нашел этот подход ... Но здесь есть ссылки stackoverflow.com/questions/931109/ и stackoverflow.com/questions/2306181/   -  person DmitryBoyko    schedule 11.01.2012

Ответы (2)


arrow_upward
4
arrow_downward

Согласно связанной статье вы должны сделать что-то вроде:

[ServiceContract(Namespace="http://api.x.com/Svc1")]
public interface IServiceNew : IService1
{
   [OperationContract(Name = "AddCustomerNew")]
   bool AddCustomer(DTOCustomer2 customer);
}

Затем внедрите его в свой сервис:

public class MyCurrentServiceImplementation : IServiceNew 
{...}

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

person tom redfern    schedule 10.01.2012
comment
Большое спасибо, очень признателен! Да, я ждал чего-то в этом роде. Осталось только определить новую конечную точку для нового контракта svc, верно? - person Learner; 11.01.2012
comment
Да, вы должны предоставить новый сервисный контракт в новой конечной точке - это сделает новую операцию доступной. - person tom redfern; 11.01.2012
comment
если раньше было «MyCurrentServiceImplementation»: «MyCurrentServiceImplementation: IService1» теперь станет «MyCurrentServiceImplementation: IServiceNew», верно? - person Learner; 11.01.2012
comment
Позвольте мне попробовать простой тест и приму ваш ответ ... Большое спасибо, Хью! - person Learner; 11.01.2012
comment
Хью, твой ответ начался в соответствии со статьей по ссылке ... Вы бы предпочли другой способ? Есть ли лучшая практика? - person Learner; 11.01.2012
comment
Это самый дешевый способ сделать это. Однако что-то в этом кажется немного взломанным. На мой взгляд, лучшим способом было бы предложить отдельную услугу с новой операцией. - person tom redfern; 11.01.2012
comment
«Новая отдельная служба» означает новый URL-адрес, контракт службы и пространство имен без наследования между двумя службами? - person Learner; 11.01.2012
comment
Даже новый хост-процесс. Да, идея состояла бы в том, чтобы разделить две операции. Тогда ими можно было бы управлять как отдельными проблемами с точки зрения управления версиями. - person tom redfern; 11.01.2012
comment
Хорошо, я вижу. Хотя я согласен с различными службами (новыми файлами .svc), возможно, я хотел бы повторно использовать некоторые параметры конфигурации из файла web.config, который является одним для всех моих служб, поскольку я храню все свои службы в одном служебном приложении, размещенном в IIS. . - person Learner; 11.01.2012
comment
Честно говоря, я не думаю, что повторное использование конфигурации будет во многом влиять на какие-либо решения, связанные с составом услуг, которые мне приходилось принимать. - person tom redfern; 11.01.2012

arrow_upward
3
arrow_downward

Очень важно отметить, что предположение, которое вы формулируете в своем сообщении:

"при изменении контракта данных необходимо определить новый контракт или контракт данных в новом пространстве имен"

не всегда верно. См. «Управление версиями контракта данных» в MSDN, чтобы узнать о ряде случаев, когда изменение контракта данных является неразрывным и поэтому может не требовать никаких действий, кроме, возможно, изменения внутренней реализации вашего метода службы для обработки наличия / отсутствия определенных данных из-за различий между версиями контракта данных.

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

Если это правда, то это очень похоже на ситуацию с необязательными аргументами при вызове метода. WCF разработан для очень хорошей обработки этого сценария как неразрывного изменения контракта данных. Если вы можете следовать рекомендациям в «Лучшие практики: управление версиями контрактов данных» в MSDN, то вызовы, предоставляющие старую или новую версию контракта, будут нормально приниматься вашим существующим интерфейсом службы. Ваш метод обслуживания получит данные, которые возможны при сочетании контрактов данных клиента и сервера.

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

person BitMask777    schedule 13.09.2012