Direct Channel usage vs using a Proxy?

As the title implies I am trying to get an understanding of why in WCF sometimes people choose to "generate proxies" vs using a ChannelFactory to manually create new channel instances. I have seen examples of each, but haven't really found any explanations of WHY you would go for one vs the other.

To be honest I have only ever worked with channels and the ChannelFactory<T> from code I have inherited, ie:

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

_duplexSessionChannel = channelFactory.CreateChannel(endpointAddress);

So why w开发者_JAVA百科ould I "generate a proxy"? What are the benefits and drawbacks?

---

The main difference is this:

• generating a proxy only requires you to know the URL where the service resides. By generating the proxy, everything else (the service contract and the data contracts involved) will be determined by inspecting the metadata of the service

• in order to directly create a ChannelFactory<T>, you must have direct access to the assembly that contains that service contract T for which you're generating a channel factory. This only ever works if you basically control both ends of the channel and you can share the assembly that contains those service contracts. Typically, with a third-party service, this won't be the case - with your own services, yes.

The second important point is this:

• creating a generated proxy basically does the two steps that you would do - create a ChannelFactory<T>, and from that, create the actual channel - in a single constructor. You have no control over these two steps.

• doing your own Channel creation is beneficial, since the creation of the ChannelFactory<T> is the expensive step - so yo could cache your channel factory instance somewhere. Creating and re-creating the actual channel from the factory is much less involved step which you can do more frequently

So if you do control both ends of the communication, service and client, you do have the option to share the service contracts in a separate assembly, and thus you have more options.

With most third-party services, you just simply don't have that option.

---

Using a proxy is simpler and easier to understand. You get to deal in terms of simple things - classes and methods on those classes - instead of complex, network-related things like channels.

OTOH, this is not made easier by the design flaw in WCF that prevents the same simple use of a WCF proxy that we could do with ASMX proxies:

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

If you use this pattern with WCF, you can lose the original exception when the block is exited due to an exception. client.Dispose() can throw an exception, which will overwrite the exception originally being thrown. A more complex pattern is required.

---

This may help you:

When to use a proxy?

If you have a service that you know is going to be used by several applications or is generic enough to be used in several places, you’ll want to use the proxy classes.

When to use ChannelFactory?

ChannelFactory class is used to construct a channel between the client and the service without the need of a proxy. In some cases, you may have a service that is tightly bound to the client application. In such a case, you can reference the Interface DLL directly and use ChannelFactory to call your methods using that.

You could also refer following link to understand the difference between Channel Factory and Proxy class http://ashishkhandelwal.arkutil.com/wcf/channelfactory-over-proxy-class-in-wcf/

---

The main advantage of the channelFactory is you can create the proxy at runtime dynamically on the fly. With SvcUtil (Add web reference in VS) you create the proxy at design time, so it's implementation is more static.