Best Practice for WCF Service Proxy lifetime?

问题:

When working with WCF services, is it better to create a new instance of the service every time you use it? Or is it better to create one and re-use it? Why is either approach better? Is it the same for asynchronous proxies?

回答1:

in addition to the things Guy Starbuck mentioned a key factor would be the security model you're using (in conjunction with the session requirements) - if you don't re-use your proxy, you can't re-use a security sessions.

This means that the client would have to authenticate itself with each call which is wasteful.

If, however, you decide this is what you wish to do, make sure to configure the client to not establish a security context (as you will never use it), this will save you a couple of roundtrips to the server :-)

回答2:

Or is it better to create one and re-use it?

Do not start to implement your own pooling implementation. That has already been done in the framework. A WCF proxy uses cached channels factories underneath. Therefore, creating new proxies is not overly expensive (but see Guy Starbuck's reply regarding sessions and security!).

Also be aware that a proxy times out after a certain idle time (10mins by default).

If you want more explicit control you might consider using ChannelFactories and channels directly instead of the "easy to go, full out of the box" ClientBase proxies.

http://msdn.microsoft.com/en-us/library/ms734681.aspx

And a "must read" regarding this topic is: http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx

回答3:

One more point to consider is channel faults. By design WCF does not allow to use client proxy after unhandled exception happened.

IMyContract proxy = new MyContractClient( );
try
{
   proxy.MyMethod( );
}
catch
{}

//Throws CommunicationObjectFaultedException
proxy.MyMethod( );

回答4:

There is a corollary here to Server Activated Objects in .NET Remoting (one of the technologies that is replaced by WCF), which have two modes, "Single Call" (stateless) and "Singleton" (stateful).

The approach you take in WCF should be based on your performance and scaling requirements in conjunction with the needs of your consumers, as well as server-side design constraints.

If you have to maintain state between calls to the service, then you will obviously want to have a stateful instance, but if you don't you should probably implement it so that it is static, which should scale better (you can more easily load balance, etc).