WCF ChannelFactory против создания прокси

Просто интересно, при каких обстоятельствах вы бы предпочли генерировать прокси из службы WCF, когда вы можете просто вызывать вызовы, используя ChannelFactory?

Таким образом, вы выигралиНужно ли создавать прокси и беспокоиться о восстановлении прокси при обновлении сервера?

Спасибо

 tom redfern31 авг. 2018 г., 15:59
Всегда используйте ChannelFactory. Я не могу утверждать это достаточно сильно.

Ответы на вопрос(6)

Прокси будет создавать асинхронные функции, для которых это довольно приятно.

 gimpf24 янв. 2013 г., 17:29
Как обновление: с .NET 4.5 ChannelFactory <T> поддерживает основанные на задачах асинхронные функции тоже.
 SandRock12 апр. 2011 г., 18:46
ChannelFactory также предоставляет асинхронные методы:msdn.microsoft.com/en-us/library/ms731177.aspx Но я предпочитаю использовать шаблон T4 для создания асинхронного класса с использованием ThreadPool, который будет вызывать синхронные методы.
 TheWommies06 дек. 2011 г., 11:52
Что такое шаблон T4?
 marc_s09 нояб. 2009 г., 07:12
да - в то же время оба Visual Studio "Добавить сервисную ссылку " а также svcutil.exe в командной строке убить ваш конфиг до неузнаваемости .... по крайней мере с svcutil.exe, вы можете определить "/ Noconfig» переключатель .....
Решение Вопроса

Существует 3 основных способа создания клиента WCF:

Позвольте Visual Studio сгенерировать ваш прокси. Этот авто генерирует код, который подключается к службе, читая WSDL. Если услуга меняется по какой-либо причине, вы должны восстановить ее. Большим преимуществом этого является то, что его легко настроить - у VS есть мастер и онВсе автоматически. Недостатком является то, что выполагаться на VS, чтобы сделать всю тяжелую работу за вас, и поэтому вы теряете контроль.

использованиеChannelFactory с известным интерфейсом. Это зависит от наличия у вас локальных интерфейсов, которые описывают услугу (контракт на обслуживание). Большим преимуществом является то, что вы можете гораздо легче управлять изменениями - вам все равно придется перекомпилировать и исправлять изменения, но теперь вывы не регенерируете код, выссылаясь на новые интерфейсы. Обычно это используется, когда вы управляете как сервером, так и клиентом, так как оба могут быть гораздо проще смоделированы для модульного тестирования. Однако интерфейсы могут быть написаны для любого сервиса, даже REST - взгляните наэто Twitter API.

Написать свой собственный прокси - это довольно легко сделать, особенно для служб REST, используяHttpClient или жеWebClient, Это дает вам самый точный контроль зерна, но за счет множества сервисных API, находящихся в строках. Например:var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - если детали API меняются, вы выиграли »не может возникнуть ошибка до времени выполнения.

Лично яМне никогда не нравился вариант 1 - полагаться на автоматически сгенерированный код беспорядочно и он теряет слишком много контроля. Кроме того, это часто создает проблемы с сериализацией - в итоге я получаю два идентичных класса (один в коде сервера, один автоматически сгенерированный), который можно исправить, но это неприятно.

Вариант 2 должен быть идеальным, но каналы немного ограничивают - например, ониполностью потерять содержание ошибок HTTP, Тем не менее, имея интерфейсы, которые описывают сервис, гораздо проще кодировать и поддерживать.

 Mare Infinitus19 авг. 2014 г., 17:52
Я думаю, что SvcUtil следует также упомянуть, так как это один из самых распространенных способов "записывать" клиент.
 Keith12 дек. 2013 г., 10:24
@MurHaf мы недаже не пришли к тем же выводам - эта статья рекомендует автоматическую генерацию прокси (вариант 1) как 'просто', Я описываю это как простую настройку, но грязную и мучительную в обслуживании. Он недаже не обсуждайте написание собственного прокси (вариант 3).
 Keith11 дек. 2013 г., 22:37
@MurHaf Нет, этот ответ - моя собственная работа. Я ВСЕГДА приписываю вклады других. Я написал этот ответ, основываясь на многолетней работе с сервисами SOAP в .Net на различных работах. Эта статья, на которую вы ссылаетесь, написана в марте 2013 года, а мой ответ был написан в апреле 2010 года - 3 года назад! Если плагиат произошел, он скопировал меня. Вы должны проверить даты, прежде чем делать обвиненияЭто очень легко сделать.

Мой ответ является своего рода сводкойКит а такжеЭндрю Харе ответы.

Если вы не управляете сервером, а имеете только WSDL / URL-адрес, создайте прокси-сервер с помощью Visual Studio или svcutil. (Обратите внимание, что Visual Studio иногда не работает, когда svcutil работает лучше).

Когда вы управляете как сервером, так и клиентом, делитесь интерфейсами / контрактами и вызывайте ChannelFactory.

Я использую ChannelFactory вместе с методом MetadataResolver.Resolve. Конфигурация клиента беспокоит, поэтому я получаю ServiceEndpoint с сервера.

Когда вы используете ChannelFactory (Of T), T является либо исходным контрактом, который вы можете получить по ссылке в вашем проекте, либо сгенерированным экземпляром контракта. В некоторых проектах я генерировал код из Service Reference, потому что не мог добавить ссылку на контрактную dll. Вы даже можете сгенерировать асинхронный контракт со ссылкой на сервис и использовать этот интерфейс контракта с ChannelFactory.

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

Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()

В моем последнем проекте, доступные привязки проверяются на использование net.tcp или net.pipe, если доступно. Таким образом, я могу использовать наилучшую доступную привязку для своих нужд. Я полагаюсь только на то, что конечная точка метаданных существует на сервере.

надеюсь, это поможет

Кстати, это делается с помощью .NET 3.5. Однако это работает и с 4.0.

 Sleeper Smith21 окт. 2011 г., 07:28
Потрясающие вещи. Я использую MetadataResolver.Resolve также для конфигурации, но я нене думаю о разрешении привязки с сервера. Очень хороший момент!
 Kurubaran03 янв. 2016 г., 23:25
Упоминание за упоминаниеThe main point of using ChannelFactory to get rid of the WCF client config

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

 Igby Largeman02 дек. 2011 г., 20:57
Это просто неправда.
 Igby Largeman15 дек. 2011 г., 17:17
@Aran: да, либо с помощью ручного кодирования, либо с помощью такого инструмента, как svcutil (при условии, что сервис работает и доступен).
 Igby Largeman14 дек. 2011 г., 18:43
@Aran: Я думаю, что Эндрю хочет сказать правильно, что если ты неЕсли вы не хотите создавать факсимиле из классов контракта, вам потребуется доступ к оригиналам. Это'Правда, так или иначе вам нужны эти контрактные классы. Вы можете сгенерировать их, написать их вручную или получить исходный код сервиса (если онна одном языке). Совместное использование сборок - это самый простой способ, но этоЭто не всегда возможно. (Может я'Я просто воспринимаю Эндрю слишком буквально, но ясность здесь важна.)
 Aran Mulholland15 дек. 2011 г., 10:06
@ Чарльз хорошо, так что вы говорите, что можете использовать ChannelFactory <T> даже если у вас не было доступа к сборкам вручную, кодируя интерфейс T и затем используя его.
 Aran Mulholland14 дек. 2011 г., 01:22
@ Чарльз - можешь объяснить, почему это не так?

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

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

Ваш ответ на вопрос