Silverlight的WCF服务代理生命周期的主题不是很清楚，我。我已阅读各种材料，资源，这里的答案，但我仍然没有完全理解使用它们假想的最好方法。

Topic of Silverlight WCF service proxy lifecycle is not very clear to me. I have read various materials, resources, answers here, but still I don't completely understand the supposed best way to use them.

我使用在Silverlight 4.0自定义的二进制结合当前。

I am using custom binary binding in Silverlight 4.0 currently.

时创建Silverlight中的一个昂贵的操作代理的？ 我们应该尝试在code共享代理实例或创建新的比较好？ 我们应该怎样做锁定，如果我们做的份额，如果多个线程访问它？

Is creation of a proxy in silverlight an expensive operation? Should we try to share proxy instance in code or create new is better? Should we do locking if we do share in case multiple threads access it?

由于在代理错误将故障代理我想分享的代理是不是一个好主意，但香港专业教育学院读的创造是昂贵的，所以它不是100％清楚该怎么做这里的状态。

Since an error on a proxy will fault the state of a proxy I think sharing a proxy isn't a good idea, but Ive read that creation is expensive, so its not 100% clear what to do here.

和带关闭 - Silverlight的WCF服务的客户端只提供CloseAsync方法。同时代理需要一定的逻辑，当它们被关闭使用（如果它们出现故障，我们应该呼吁中止（），它是同步在Silverlight中，如果不是我们应该CloseAsync这是不同步的还是什么？）。

And with closing - silverlight WCF service clients only provide CloseAsync method. Also proxies require certain logic to be used when they are closed ( if they are faulted we should call Abort() which is synchronous in Silverlight and if not we should CloseAsync which is not synchronous or what?).

在从微软代理许多官方的Silverlight样品不收任何，是，仅仅缺陷的材料或预期的方式给他们？

In many official Silverlight samples from MS proxies are not closed whatsoever , is that just flaw of materials or expected approach to them?

话题对我来说很重要，我想那应该算是我目前还没有所有的事情一个清晰的认识。

Topic is very important to me and I want a clear understanding of all things that should be considered which I currently don't have.

（我没有看到这个问题的What是在Silverlight 3 WCF服务客户端代理的正常生命周期？似乎接近我的，但我不能说我很满意答案的质量）

( I did see that this question What is the proper life-cycle of a WCF service client proxy in Silverlight 3? appears close to mine but I cannot say I am satisfied with quality of answers)

我真的想看看样品code使用，创建，关闭等WCF代理，最重要的解释，为什么这是最好的方式。我也觉得（目前认为），因为问题的性质是，应该有一个单一的，一般使用的最佳做法/模式 - 采用何种方法（创建，重用，关闭）WCF代理在Silverlight。

I would really like to see sample code that uses, creates , closes etc WCF proxies, and most importantly explains, why that is the best possible way. I also think (currently believe) that because of nature of problem, there should be a single, general use best practice/pattern - approach to use (create,reuse,close) WCF proxies in Silverlight.

推荐答案

摘要：我认为最好的做法是，以实例化Web服务客户端，当你要使用它，然后让​​它去超出范围，让垃圾回收。这体现你看到来自微软的样本。理由如下...

Summary: I believe the best practice is to instantiate your web service client when you are about to use it, then let it go out of scope and get garbage collected. This is reflected in the samples you see coming from Microsoft. Justification follows...

全部：我发现这个过程的最好的完整描述是的如何：访问Silverlight的的服务。下面的例子显示实例化Web服务客户端，并允许其超出范围的典型模式（无需关闭）。 Web服务客户端继承自ClientBase有，应该释放任何非托管资源，如果需要的话，当对象被垃圾回收Finalize方法。

Full:The best full description of the process that I have found is at How to: Access a Service from Silverlight. Here the example shows the typical pattern of instantiating the web service client and allowing it to go out of scope (without needing to close it). Web service clients inherit from ClientBase which has a Finalize method that should free any unmanaged resources if necessary when the object is garbage collected.

我有一个使用Web服务的经验，一个体面的数额，而我使用代理服务器和实例他们的权利在使用前，然后让他们进行垃圾回收。我从未有过这种方法的一个问题。我读Wenlong董的博客里面说，创建代理的是昂贵的，但即使他说，性能有所提升在.NET 3.5（也许它再次从那以后改进？）。我的可以的告诉你的是，性能是相对而言的，除非被检索的数据少于琐碎的大小，更多的时间将在序列化/反序列化和运输不是创建的连接中度过。这无疑是我的经验，你是最好的优化在这些领域的第一。

I have a decent amount of experience using web services, and I use proxies and instantiate them right before use, then allow them to be garbage collected. I have never had a problem with this approach. I read on Wenlong Dong's Blog which said that creation of the proxy was expensive, but even he says performance has improved in .NET 3.5 (perhaps it has improved again since then?). What I can tell you is that performance is a relative term, and unless your data being retrieved is less than trivial in size, far more time will be spent in serializing/deserializing and transport than creating the connection. This has certainly been my experience, and you are better off optimizing in those areas first.

最后，因为我认为我的意见迄今可能是不够的，我写了一个快速测试。我使用具备的Visual Web Developer 2010例preSS的模板创建一个Silverlight功能的Web服务（一个名为default无效的方法的DoWork（））。然后在我的示例Silverlight客户端我把它叫做用下面的code：

Last, since I figure my opinions thus far may be insufficient, I wrote a quick test. I created a Silverlight enabled web service using the template provided with Visual Web Developer 2010 Express (with a default void method called DoWork()). Then in my sample Silverlight client I called it using the following code:

int counter=0;
public void Test()
{
    ServiceReference1.Service1Client client = new ServiceReference1.Service1Client();
    client.DoWorkCompleted += (obj, args) => 
    { 
        counter++;
        if (counter > 9999)
        {
            for(int j=0;j<10;j++) GC.Collect();
            System.Windows.MessageBox.Show("Completed");
        }
    };
    client.DoWorkAsync();
}

我当时叫测试方法，使用的for（int i = 0; I＆LT; 10000;我++）测试（）; 和发射了该应用程序。它花了一点了20秒加载的应用程序和放大器;完成Web服务调用（全部10000个人）。由于正在做出的Web服务调用我看到了这个过程跳转到150MB以上的内存使用量，但一旦完成了电话和 GC.Collect的（）被称为内存使用情况下降到小于一半的量。远不是一个完美的测试似乎证实，我认为没有记忆漏水，也可以忽略不计（考虑到它可能是罕见的来电信息全部采用单独的客户端实例万Web服务）。此外，它是一个非常简单的模型不是围绕保持一个代理对象，并不必担心断裂，不得不重新打开它。

I then called the Test method using for(int i=0;i<10000;i++) Test(); and fired up the application. It took a little over 20 seconds to load up the app & complete the web service calls (all 10,000 of them). As the web service calls were being made I saw the memory usage for the process jump to over 150MB, but once the calls completed and GC.Collect() was called the memory usage dropped to less than half that amount. Far from being a perfect test it seems to confirm to me that no memory was leaking, or it was negligible (considering it is probably uncommon to call 10,000 web service calls all using separate client instances). Also it is a much simpler model than keeping a proxy object around and having to worry about it faulting and having to reopen it.

测试方法的理由： 我的测试集中在2潜在的问题。一个是内存泄漏，而另一个是用了创建和销毁对象处理器时间。我的建议是，它是安全的追随由公司（微软）谁提供的类提供的实例。如果您担心网络的效率，那么你应该有我的例子中没有问题，因为正确创建/配置这些对象不会影响网络延迟。如果99％所用的时间是网络时间，然后优化在1％的理论的改进是在开发时间上（假设可能浪费甚至还有一个可以得到的，我相信我的测试清楚地表明几乎没有什么好处/无）。是的，网络电话都是本地这是说，超过10000服务呼叫的过程中，只有约20秒将被用于等待的对象。这再presents〜2毫秒每个服务呼叫的花费在创建对象。对于需要调用Dispose，我不是故意要暗示你的不应该的调用它，只是它没有出现必要的。如果您忘记了（或者干脆选择不），我的测试使我相信，在处置被称为在最后确定这些对象。即便如此，它很可能是更有效地调用Dispose自己，但仍是影响可忽略不计。对于大多数软件开发您想出更有效的算法和数据结构比思念过这样的问题（除非有严重的内存泄漏）获得更多的收益。如果您需要更高的效率，那么也许你不应该使用Web服务，因为还有比一个基于XML的系统更加高效的数据中转的选择。

Justification of Test Methodology: My test focused on 2 potential problems. One is a memory leak, and the other is processor time spent creating and destroying the objects. My recommendation is that it is safe to follow the examples provided by the company (Microsoft) who supplies the classes. If you are concerned about network efficiency, then you should have no problem with my example since properly creating/disposing these objects would not effect network latency. If 99% of the time spent is network time, then optimizing for a theoretical improvement in the 1% is probably wasteful in terms of development time(assuming there is even a benefit to be gained which I believe my test clearly shows there is little/none). Yes, the networking calls were local which is to say that over the course of 10,000 service calls, only about 20 seconds will be spent waiting for the objects. That represents ~2 milliseconds per service call spent on creating the objects. Regarding the need to call Dispose, I didn't mean to imply that you shouldn't call it, merely that it didn't appear necessary. If you forget (or simply choose not to), my tests led me to believe that Dispose was being called in the Finalize for these objects. Even so, it would probably be more efficient to call Dispose yourself, but still the effect is negligible. For most software development you get more gains from coming up with more efficient algorithms and data structures than by pining over issues like these (unless there is a serious memory leak). If you require more efficiency, then perhaps you shouldn't be using web services since there are more efficient data transit options than a system that is based on XML.