Dispatcher/Proxy（客户端）扩展可提高WCF服务的吞吐量

需要一些专家对这个案例研究的意见

问题陈述/场景： 我的WCF客户端/代理不断要求相关WCF服务提供一些锁定数据。更准确地说，我有一个WCF服务，它从数据库中提供位置数据（城市/国家等）（尽管数据缓存在服务中）。我希望避免序列化/反序列化（对象包含大量相关属性以及内部对象）的一些方法，以降低成本和服务操作执行，从而获得更好的吞吐量

几天前，我研究了WCF行为/WCF扩展方法(http://msdn.microsoft.com/en-us/magazine/cc163302.aspx). 读完这篇文章后，我认为这可以帮助我提高服务的性能。所以在实施之前，我想确认我的思路是否正确，或者任何其他解决方案都可以解决我的问题

我想实现Dispatcher扩展来解决这个问题，而不是代理（客户端）扩展。我有以下问题吗

一） 我需要在哪里（代理/服务级别）实现扩展？ 二） 在实现Dispatcher扩展时，我的调用不会发送到实际的服务，这样可以节省序列化/反序列化成本。对/错？ 三） 在我的例子中实现Dispatcher扩展也更好，因为既然缓存逻辑在服务端，为什么不必担心发生了哪个代理接口方法调用呢。对/错

请为我推荐一个更好的解决方案，因为我希望节省序列化/反序列化成本，并且我希望实现数据缓存

提前谢谢

---

/Rizwan

在过去，我采用了两种方式合并WCF缓存：

使用Castle DynamicProxy为我的ServiceContract接口生成代理。这些动态代理使用拦截器执行缓存。如果数据不在缓存中，拦截器将创建一个真正的WCF客户端（一个

ChannelFactory

）并调用WCF操作，然后缓存结果。我喜欢这种方法，因为缓存实现实际上并不特定于WCF

为WCF实现一个IRealProxy，它包装实际的远程操作，并根据需要执行缓存/检索。原则上，这类似于方法1，但实现是特定于WCF的（带有.NET远程处理的残余）。在迁移到#1之前，我使用了这种方法。我迁移到方法1，因为方法1允许我以实现无关的方式在客户端和服务器上完成缓存。当时，我推出了自己的RealProxy，但似乎有人也这么做了，并发布了代码：

---

当多个应用程序正在使用我的服务，并且每个应用程序都有自己的代理类缓存数据，最终导致服务上的数据不匹配时，会发生什么。例如，Proxy1调用位置服务并请求位置“伦敦”数据，服务为Proxy1调用提供数据并将数据提供给它，Proxy1将其缓存。现在，Proxy2调用服务并更新位置“伦敦”数据，服务为Proxy2提供服务，并将更新该端的数据，而Proxy2将缓存该数据。现在Proxy1调用了同一个位置“伦敦”，并在本地端找到它，但不知道数据在服务中更新了吗？