Использование прямого канала или использование прокси?

Question

Как следует из названия, я пытаюсь понять, почему в WCF иногда люди предпочитают «генерировать прокси» вместо использования ChannelFactory для ручного создания новых экземпляров канала.Я видел примеры каждого из них, но не нашел никаких объяснений, ПОЧЕМУ вы выберете один, а не другой.

Честно говоря, я когда-либо работал только с каналами и ChannelFactory<T> из кода, который я унаследовал, то есть:

IChannelFactory<IDuplexSessionChannel> channelFactory =
    binding.BuildChannelFactory<IDuplexSessionChannel>();

_duplexSessionChannel = channelFactory.CreateChannel(endpointAddress);

Так зачем мне «создавать прокси»?Каковы преимущества и недостатки?

Answer 1

Основное отличие заключается в следующем:

• для создания прокси-сервера вам необходимо знать только URL-адрес, по которому находится служба.При создании прокси все остальное (контракт службы и соответствующие контракты данных) будет определяться путем проверки метаданных службы.

• чтобы непосредственно создать ChannelFactory<T>, у вас должен быть прямой доступ к сборке, содержащей этот контракт службы. T для которого вы создаете фабрику каналов.Это работает только в том случае, если вы фактически контролируете оба конца канала и можете поделиться сборкой, содержащей эти сервисные контракты.Обычно со сторонним сервисом такого не происходит, с вашими — да.

Второй важный момент заключается в следующем:

• создание сгенерированного прокси-сервера в основном выполняет два шага, которые вы бы сделали: создайте ChannelFactory<T>, и на его основе создайте реальный канал — в одном конструкторе.Вы не можете контролировать эти два шага.

• создание собственного канала полезно, поскольку создание ChannelFactory<T> это дорогостоящий шаг - поэтому вы можете где-нибудь кэшировать экземпляр фабрики каналов.Создание и воссоздание фактического канала с завода — гораздо менее трудоемкий шаг, который вы можете выполнять чаще.

Таким образом, если вы контролируете обе стороны связи, службу и клиента, у вас есть возможность разделить контракты службы в отдельной сборке, и, таким образом, у вас будет больше возможностей.

В большинстве сторонних сервисов у вас просто нет такой возможности.

Answer 2

Использование прокси проще и понятнее.Вам приходится иметь дело с простыми вещами — классами и методами этих классов — вместо сложных, связанных с сетью вещей, таких как каналы.

OTOH, это не упрощается из-за конструктивного недостатка WCF, который не позволяет использовать прокси-сервер WCF так же просто, как мы могли бы сделать с прокси-серверами ASMX:

using (var client = new MyServiceClient())
{
}

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

Answer 3

Это может помочь вам:

Когда использовать прокси?

Если у вас есть служба, которая, как вы знаете, будет использоваться несколькими приложениями или является достаточно универсальной, чтобы ее можно было использовать в нескольких местах, вам следует использовать прокси-классы.

Когда использовать ChannelFactory?

Класс ChannelFactory используется для создания канала между клиентом и службой без необходимости использования прокси.В некоторых случаях у вас может быть служба, тесно привязанная к клиентскому приложению.В таком случае вы можете напрямую ссылаться на интерфейсную DLL и использовать ChannelFactory для вызова своих методов с ее помощью.

Вы также можете перейти по следующей ссылке, чтобы понять разницу между Channel Factory и классом прокси.http://ashishkandelwal.arkutil.com/wcf/channelfactory-over-proxy-class-in-wcf/

Answer 4

Основное преимущество ChannelFactory заключается в том, что вы можете динамически создавать прокси во время выполнения.С помощью SvcUtil (добавление веб-ссылки в VS) вы создаете прокси-сервер во время разработки, поэтому его реализация более статична.