#wcf #wcf-client
#wcf #wcf-клиент
Вопрос:
Я новичок в WCF. Первоначально я создал службу WCF и использовал сгенерированный клиентский прокси для использования службы от клиента. Поэтому всякий раз, когда я выполнял некоторые операции над сервисом, все выполнялось последовательно, поскольку я вызываю операции синхронно. Я изменил режим параллелизма на несколько, но все равно операции выполнялись синхронно. Затем я сгенерировал асинхронные методы для своих операций и использовал шаблоны begin / end, которые, как я полагаю, «освободили» канал и позволили операциям выполняться параллельно / асинхронно, увеличивая пропускную способность моих приложений.
Затем я использовал ChannelFactory
для создания канала и выполнял операции, поскольку клиент и сервер могут совместно использовать контракты (один и тот же проект). Но IClientChannel
предоставляет только BeginOpen/EndOpen/BeignClose/EndClose
. У него нет методов ClientBase
. BeginOperation/EndOperation
Таким образом, в принципе я не могу выполнить операцию асинхронно на канале, чтобы освободить место, чтобы я мог использовать канал для выполнения других операций.
Я просто создал каналы для каждой операции, и это решило проблему
Итак, мой вопрос:
-
Что лучше (
ClientBase vs. ChannelFactory
) в соответствии с моим сценарием, особенно я хочу выполнять несколько операций над объектом service одновременно с несколькими потоками -
Целесообразно ли создавать канал для каждой операции?
-
На самом деле, я думал, что у нас может быть только один канал между двумя конечными точками (клиент / сервис). Но я могу создать столько каналов, сколько захочу. Например: я смог создать Int16.MaxValue каналов. Так что не уверен, какой предел и рекомендации по этому поводу.
Service[] channels = new IService[Int16.MaxValue]; for(int i = 0; i<Int16.MaxValue; i ) { channels[i] = factory.CreateChannel(); }
Итак, в принципе, не могли бы вы, пожалуйста, сообщить мне об основах каналов, рекомендациях, хитростях и т. Д. И т. Д. 🙂
Ответ №1:
Существует разница в использовании асинхронности между ClientBase
и ChannelFactory<T>
. В основном ClientBase
используется асинхронная модель, управляемая событиями.
Я ChannelFactory<T>
широко использовал в приложении, которое я разработал на работе, главным образом потому, что контракты были доступны в общей библиотеке для приложения, и мне не нравится использовать ссылку Add Service. Я кэширую каждый уникальный экземпляр ChannelFactory при создании, а затем, когда мне нужно вызвать операцию, я открою канал связи из этого экземпляра, сделаю свой вызов и закрою канал связи.
Большая часть затрат на запуск WCF связана с созданием клиента, и таким образом вы платите только один раз за жизнь приложения — создание каналов связи тривиально.
Для получения дополнительной информации об асинхронности для ClientBase
и ChannelFactory<T>
см.:
Как: асинхронно вызывать операции службы WCF
Как: асинхронно вызывать операции с использованием фабрики каналов
Комментарии:
1. Спасибо, Тим. Да, я тоже делаю почти то же самое. Создание нового канала связи для каждой операции и его закрытие. Я просмотрел ссылки, но у меня все еще есть некоторые вопросы. 1. Сколько каналов рекомендуется? 2. ДЛЯ синхронного выполнения операций с использованием фабрики каналов нам просто нужно добавить методы BeginOp / EndOp в интерфейс канала. об остальном позаботится WCF — другими словами, svcutil util генерирует так много кода, который нас не интересует. нас интересует только определение интерфейса, и пусть WCF выполняет тяжелую работу. Если да, это круто.
2. Вопросы в дополнение к приведенным выше?
3. @Dreamer — я не думаю, что есть какое-либо рекомендуемое количество каналов. Если у вас много клиентов, у вас могут возникнуть проблемы с одновременным подключением, но вы можете настроить это в конфигурации. Что касается вашего второго вопроса, я еще не сделал ничего асинхронного в WCF (мы готовимся сделать это в нашей следующей версии на работе), но я думаю, что пока интерфейс правильный, все должно быть в порядке.
4. спасибо, Тим. Кстати, у вас была возможность взглянуть на мой другой вопрос (WCF — создание нескольких экземпляров службы для одного клиента на основе тега / условно (не на основе percall)