Использование Прямого канала по сравнению с использованием Прокси?
Поскольку заголовок подразумевает, что я пытаюсь получить понимание того, почему в WCF иногда люди принимают решение "генерировать прокси" по сравнению с использованием ChannelFactory для ручного создания новых экземпляров канала. Я видел примеры каждого, но действительно не нашел объяснений того, ПОЧЕМУ Вы пошли бы для одного по сравнению с другим.
Чтобы быть честным, я только когда-либо работал с каналами и ChannelFactory<T> из кода я наследовался, т.е.:
IChannelFactory<IDuplexSessionChannel> channelFactory =
binding.BuildChannelFactory<IDuplexSessionChannel>();
_duplexSessionChannel = channelFactory.CreateChannel(endpointAddress);
Итак, почему был бы я "генерировать прокси"? Каковы преимущества и недостатки?
2 ответа
Основное различие заключается в следующем:
генерация прокси требует от вас только знания URL, где находится сервис. При генерации прокси все остальное (контракт сервиса и контракты данных) будет определяться путем изучения метаданных сервиса
чтобы напрямую создать
ChannelFactory, вы должны иметь прямой доступ к сборке, содержащей тот контракт сервисаT, для которого вы создаете фабрику каналов. Это работает только в том случае, если вы контролируете оба конца канала и можете совместно использовать сборку, содержащую эти сервисные контракты. Как правило, со сторонними сервисами это не так, а с вашими собственными - да.
Второй важный момент заключается в следующем:
создание сгенерированного прокси, по сути, выполняет два шага, которые вы должны сделать - создать
ChannelFactory, и из него создать фактический канал - в одном конструкторе. У вас нет контроля над этими двумя шагами.создание собственного канала выгодно, так как создание
ChannelFactoryявляется дорогостоящим шагом - поэтому вы можете где-то кэшировать экземпляр фабрики каналов. Создание и повторное создание фактического канала из фабрики - гораздо менее затратный шаг, который вы можете выполнять чаще
Таким образом, если вы контролируете оба конца коммуникации, сервис и клиент, у вас есть возможность разделить контракты сервиса в отдельной сборке, и таким образом у вас больше возможностей.
С большинством сторонних сервисов у вас просто нет такой возможности.
Использование прокси проще и понятнее. Вы можете иметь дело с простыми вещами - классами и методами этих классов - вместо сложных, связанных с сетью вещей, таких как каналы.
OTOH, это не упрощается из-за недостатка конструкции в WCF, который не позволяет использовать такое же простое использование прокси-сервера WCF, которое мы могли бы использовать с прокси-серверами ASMX:
using (var client = new MyServiceClient())
{
}
Если вы используете этот шаблон с WCF, вы можете потерять исходный исключение, когда блок выходит из-за исключения. client.Dispose () может вызвать исключение, которое перезапишет исходное исключение. Требуется более сложный узор.