Share your interfaces – avoid static proxies.

When using WCF services, we have several options for creating the proxies. We can create them statically using SVCUTIL or the build-in IDE support (Add Service Reference…), or we can generate them dynamically using the ChannelFactory or GenericProxy approaches.

The advantage of the static proxy approach is that it we local code for us based on remote metadata (WSDL). Even if the service is somewhere out of our reach and control, all we need is for it to expose metadata for us to access it. We get a copy of the service contract and interfaces and we’re good to go.
The problems with it is that I have to maintain that proxy. If the service changes, our proxy needs to adapt too. I’m not referring to versioning issues and new methods added, but to big changes in the service contract itself. This may not be an issue when accessing stable services, but certainly happens a lot during development.

The second approach is much more limited – for it to work we need to have a reference to a shared assembly containing the contracts. It means our services and contracts are .NET classes using the WCF framework, rather than generic WS-* services that can have any implementation. This approach is only useful when we have access to the our services’ code or assemblies, so it’s out of the question for public services.
In short, the dynamic proxy approach is only for use when we control both client and server in the scope of a single application (or group of familiar applications).

But in this context, this is the best way to work. I’ll stress the point again – if we meet all the criteria above for using dynamic proxies, we should use them without hesitation.
The amount of work that goes into maintaining the static proxies, making sure that the client and server copies of the contracts are identical, hours of debugging mysterious errors caused by contract mismatches – all with perplexing error messages and little documentation – all these things are simply not worth it.

I’ll say it again – if you’re writing an N-tier application that uses WCF for communication, have the contracts shared by both client and server and use the GenericProxy class to access it rather than relying on generated proxies and SVCUTIL. Trust me. Your deadline will thank you for it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.