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

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 и Proxy class http://ashishkhandelwal.arkutil.com/wcf/channelfactory-over-proxy-class-in-wcf/

Answer 4

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