Альтернатива сервисной ссылке

Question

Я пытаюсь помочь одной команде проекта упорядочить свою работу, исправив некоторые болевые точки.

Одна из проблем, с которыми они сталкиваются в своем коде, заключается в том, что они используют службу WCF через ссылки на службы (прокси-сервер) [т.е. «Добавить ссылку на службу» в Visua Studio 2008. Это создает много проблем, включая накладные расходы на развертывание, Souce Control получает последние связанные проблемы обновления прокси и т. Д.

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

Однако проблема в том, что эти службы используют много кода, подобного этому

BatchClient client = new BatchClient(); //Batchclient is  a proxy
batchData = client.GetBatchData(batchNumber)

Так что, если я пойду по пути ChannelFactory, мне потребуется обновить весь фрагмент кода, как описано выше, по всему проекту. Из-за большого количества изменений команде не очень комфортно с этой опцией.

Вопрос, который у меня возникает, заключается в том, существует ли какая-либо другая лучшая альтернатива «Добавить ссылку на службу», которую можно использовать с минимальными изменениями кода? Или я мог бы использовать ChannelFactory, не затрагивая фрагменты кода?

Answer 1

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

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

Задайте себе следующие вопросы (или, скорее, объясните мне):

• Каковы затраты на развертывание?Я не вижу никого.Созданный вами прокси будет работать после развертывания.Вы изменяете адрес службы и поведение в файле конфигурации.
• Проблемы с контролем версий / последние?Это также не должно быть проблемой.Просто получите последнюю версию и используйте самую последнюю.Если служба изменилась - и вы хотите воспользоваться этими изменениями - вам потребуется получить последнюю версию контракта на обслуживание, если вы используете общий файл контракта и создаете свой собственный канал.
• Обновлениепрокси?Недостаточная осведомленность о том, как работает прокси-сервер, что это такое и что он делает, может вызвать это, но опять же, без прокси-сервера не легче.На самом деле, вы просто щелкаете правой кнопкой мыши вверх, выбирая «Обновить справочник услуг», верно?

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

Answer 2

В некоторых статьях предлагается использовать класс ClientBase для достижения той же цели.

См. А) https://aturcarablog.wordpress.com/2016/08/07/alternative-way-to-consume-wcf-service/

b) http://www.codeproject.com/Articles/412363/How-to-Use-a-WCF-Service-without-Adding-a-Service

Таким образом,Ваш код может быть переписан как:

using (var batchClient = new ServiceWrapper<IYourWcfService>("YourEndpointConfigurationName"))
{
    batchData = batchClient.Proxy.GetBatchData(batchNumber);
}