WCF ChannelFactory vs generating proxy

Question

Just wondering under what circumstances would you prefer to generate a proxy from a WCF service when you can just invoke calls using the ChannelFactory?

This way you won't have to generate a proxy and worry about regenerating a proxy when the server is updated?

Thanks

Michaelmichaela

Always use ChannelFactory. I cannot state this strongly enough. – Spoonful

Answer 1

There are 3 basic ways to create a WCF client:

1. Let Visual Studio generate your proxy. This auto generates code that connects to the service by reading the WSDL. If the service changes for any reason you have to regenerate it. The big advantage of this is that it is easy to set up - VS has a wizard and it's all automatic. The disadvantage is that you're relying on VS to do all the hard work for you, and so you lose control.

2. Use ChannelFactory with a known interface. This relies on you having local interfaces that describe the service (the service contract). The big advantage is that can manage change much more easily - you still have to recompile and fix changes, but now you're not regenerating code, you're referencing the new interfaces. Commonly this is used when you control both server and client as both can be much more easily mocked for unit testing. However the interfaces can be written for any service, even REST ones - take a look at this Twitter API.

3. Write your own proxy - this is fairly easy to do, especially for REST services, using the HttpClient or WebClient. This gives you the most fine grain control, but at the cost of lots of service API being in strings. For instance: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - if the details of the API change you won't encounter an error until runtime.

Personally I've never liked option 1 - relying on the auto generated code is messy and loses too much control. Plus it often creates serialisation issues - I end up with two identical classes (one in the server code, one auto generated) which can be tided up but is a pain.

Option 2 should be perfect, but Channels are a little too limiting - for instance they completely lose the content of HTTP errors. That said having interfaces that describe the service is much easier to code with and maintain.

Tiffanietiffanle

I think SvcUtil should be mentioned also, as this is one of the most common ways to "write" a client. – Ladner

Answer 2

I use ChannelFactory along with MetadataResolver.Resolve method. Client configuration is a bother, so I get my ServiceEndpoint from the server.

When you use ChannelFactory(Of T), T is either the original contract that you can get from a reference in you project or a generated contract instance. In some projects, I generated the code from a Service Reference because I could not add a reference to the contract dll. You can even generate an asynch contract with the service reference and use that contract interface with ChannelFactory.

The main point of using ChannelFactory for me was to get rid of the WCF client config information. In the sample code below, you can see how to achieve a WCF client without config.

Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()

In my final project, the availableBindings are checked to use net.tcp or net.pipe if available. That way, I can use the best available binding for my needs. I only rely on the fact that a metadata endpoint exist on the server.

I hope this helps

BTW, this is done using .NET 3.5. However it does work also with 4.0.

Dwain

Awesome stuff. I use MetadataResolver.Resolve as well for config but I didn't think about resolving the binding from the server. Very good point! – Indicator

upvote for mentioning The main point of using ChannelFactory to get rid of the WCF client config – Enquire

Answer 3

Well in order to use ChannelFactory<T> you must be willing to share contract assemblies between the service and the client. If this is okay with you then ChannelFactory<T> can save you some time.

Zorazorah

@Charles - can you explain why this is not true? – Flank

@Aran: I think what Andrew means to say is correct - that if you don't want to generate facsimiles of the contract classes, then you would need to have access to the originals. It's true that one way or another you need to have those contract classes. You can generate them, write them by hand, or get the service source code (if it's in the same language). Sharing assemblies is the easiest way, but that's not always possible. (Maybe I'm just taking Andrew too literally, but clarity is important here.) – Horsey

@Charles ok, so you are saying that you could use ChannelFactory<T> even if you had no access to the assemblies by hand coding the interface of T and then using that. – Flank

@Aran: yes, either by hand-coding or by using a tool like svcutil(assuming the service is running and accessible). – Horsey

Answer 4

The proxy will build async functions for which is kind of nice.

Hautevienne

yes - at the same time, both Visual Studio's "Add Service Reference" as well as svcutil.exe on the command line slaughter your config beyond recognition.... at least with svcutil.exe, you can define a "/noconfig" switch..... – Kumasi

ChannelFactory also provides async methods: msdn.microsoft.com/en-us/library/ms731177.aspx But I prefer to use a T4 template to create an async class using ThreadPool which will invoke synchronous methods. – Perambulate

As an update: With .NET 4.5 ChannelFactory<T> supports task-based asynchronous functions too. – Boneyard

Answer 5

My answer is a kind of summary of Keith's and Andrew Hare's answers.

If you do not control server, but have only WSDL/URL- generate proxy using Visual Studio or svcutil. (Note that Visual Studio sometimes failed, when svcutil works better).

When you control both server and client, share interfaces/contracts and call ChannelFactory
.

Monochrome

Answer 6

It's not just a matter of time saved. Using the WSDL generated proxy is dangerous because if you forget to update the service reference you can leave the solution in an inconsistent state. Everything compiles but the service contract is broken. I definetly suggest to use a ChannelFactory whenever possible, you make your life much easier.

A possible alternative could be to write a prebuild script that calls the SVCUtil utility to create the proxy everytime you build your project, but anyway ChannelFactory is much more neat and elegant.

Smacker