Разве добавление метода в WCF ServiceContract нарушает работу существующих клиентов?
У нас есть существующий ServiceContract
[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
[OperationContract(IsOneWay = true)]
void ProcessMessage(Message message);
[OperationContract(IsOneWay = true)]
void ProcessMessageResult(MessageResult result);
}
и нам нужно добавить метод к нему
[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
[OperationContract(IsOneWay = true)]
void ProcessMessage(Message message);
[OperationContract(IsOneWay = true)]
void ProcessMessageResult(MessageResult result);
[OperationContract(IsOneWay = true)]
void ProcessBlastMessage(BlastMessage blastMessage);
}
Это сломает какие-либо существующие клиенты wcf, которые используют этот сервис? Или нам придется обновить все существующие клиенты wcf?
РЕДАКТИРОВАТЬ: эта служба использует как netTcpBinding и netMsmqBinding
5 ответов
Я думаю, что ваши существующие клиенты будут продолжать работать. В конце концов это очень похоже на SOAP и веб-сервисы в том, что клиент будет подключаться к указанному URL-адресу и запрашивать конкретный сервис. Если вы уберете методы, вы рискуете сломаться (я полагаю, что только при использовании метода), но добавление должно быть безболезненным.
Я только баловался с WCF, но с таким успехом использовал веб-сервисы ASP.NET.
Я только что протестировал это с клиентским приложением WCF для Windows (UWP), и оно продолжало работать после обновления приложения-службы WCF. Так что нет: как уже отвечали ранее, ваши клиенты не сломаются, когда вы добавите метод.
Однако я подумал, что стоит упомянуть, как легко обновлять клиенты службы с помощью Visual Studio 2015:
Убедитесь, что ваш сервис WFC работает.
Просто зайдите в
Solution Explorer
,расширять
Service References
Щелкните правой кнопкой мыши ссылку на сервис
Нажмите
Update Service Reference
Если вы получили сообщение об ошибке, повторите последний шаг. Мне пришлось попробовать несколько раз по какой-то причине.
Нет, я бы не ожидал, что добавление новой функциональности / новых методов обслуживания, которые НЕ изменяют ни один из существующих вызовов методов / функций, не повлияет на "старых" клиентов. Конечно, они не будут знать о новых методах, пока их прокси не будут воссозданы из метаданных или адаптированы вручную.
Но существующие вызовы не должны быть затронуты, пока их подпись (данные, которыми они обмениваются) остается неизменной.
Марк
Я придерживаюсь более крайнего взгляда на это. Зачем что-то менять? Вместо этого, почему бы не создать новый контракт, унаследовав от старого и добавив новую операцию? Новый контракт может быть выставлен в отдельной конечной точке в том же сервисе.
Это может быть паранойя, неосведомленная формальным доказательством, но мне кажется, что, если возможно создать клиента, который может отличить, то возможно, что какой-то клиент "сломается", когда вы сделаете изменение. Учтите, что когда вы изменяете контракт на обслуживание, вы не просто изменяете код службы - вы меняете код прокси-сервера в любом клиенте, который обновляет его ссылку на службу. Некоторые, более консервативные клиенты, могут посчитать это причиной для повторного тестирования своего клиентского кода - в конце концов, у них могут быть правила, согласно которым они должны повторно тестировать свой код всякий раз, когда в него вносятся какие-либо изменения.
Существующий клиент будет ссылаться на исходную конечную точку, поэтому на него не повлияет добавление новой конечной точки - ни один код не изменится, если будет выполнено "Обновление справочной службы".
Кроме того, зачем даже думать об этом, если не нужно?
В общем, добавление к сообщению в SOA-решениях не нарушает контракт. Я считаю, что пока вы не используете двоичный протокол (net.tcp), вы будете поддерживать обратную совместимость.
Я не уверен в том, что он сломает ваши клиенты, используя двоичные привязки?