Очень важно отметить, что предположение, которое вы указали в своем сообщении:
"при изменении контракта данных необходимо определить новый или контракт контракта данных в новом пространстве имен"
не всегда верно.См. «Создание версий контракта данных» на MSDN для ряда случаев, когда изменение контракта на данные не нарушает и, следовательно, может не требовать никаких действий, кроме, возможно, изменения внутренней реализации вашей службы.метод для обработки наличия / отсутствия определенных данных из-за различий между версиями контракта данных.
В этом конкретном примере я хотел бы спросить, как две версии метода с именем AddCustomer
могут настолько сильно различаться по своему предназначению, чтооправдывает создание нового интерфейса сервиса.Не видя ваших старых и новых контрактов на данные, я не могу знать наверняка, но я предполагаю, что реальная проблема заключается в том, что этот метод эволюционировал, чтобы принимать дополнительную информацию о клиентах.
Если это правда, то этоочень похоже на ситуацию необязательных аргументов в вызове метода.WCF разработан для того, чтобы очень хорошо справляться с этим сценарием как неразрывное изменение контракта на данные.Если вы можете следовать рекомендациям, изложенным в «Наилучшие практики: управление версиями контракта данных» на MSDN, то вызовы, поставляющие либо старую, либо новую версию контракта, будут прекрасно приниматься вашим существующим Сервисный интерфейс.Ваш сервисный метод получит данные, которые возможны, учитывая комбинацию контрактов данных клиента и сервера.
Я бы оставил свой сервисный интерфейс целостным, простым и чистым (т.е. избегал бы таких действий, как IServiceNew), а вместо этого простодобавьте к контракту данных и измените реализацию AddCustomer
, чтобы адаптировать ее к любым полученным данным.