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

Question 1

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

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

благодаря

Question 2

Есть 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 . При этом, имея интерфейсы, описывающие сервис, намного проще кодировать и поддерживать.

Question 3

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

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

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

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()

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

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

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

Question 4

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

Question 5

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

Question 6

Мой ответ - это своего рода резюме ответов Кита и Эндрю Хейров .

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

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

Question 7

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

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