需要一些关于此案例研究的专家意见。
问题陈述/情景： 我的WCF客户端/代理不断需要来自相关WCF服务的一些锁定数据。更确切地说，我有一个WCF服务，它从数据库提供位置数据（城市/国家等）（尽管数据缓存在服务上）。一些我如何避免序列化/ DeSerialization（对象包含许多相关属性以及内部对象）成本和服务操作执行以获得更好的吞吐量。
几天前我研究了WCF行为/ WCF扩展方法。我在MSDN上发现了一篇有趣的文章（http://msdn.microsoft.com/en-us/magazine/cc163302.aspx）。阅读本文后，我认为这可以帮助我提高服务的性能。所以在实现这个之前，我想确认我正在考虑正确的方向或任何其他解决方案可以解决我的问题。
我正在考虑实现Dispatcher Extensions来解决此问题而不是Proxy（Client）Extensions。我有以下问题吗？
I）哪里（代理/服务级别）我需要实现扩展？ II）当实现Dispatcher Extensions时，我的调用将不会发送到实际服务，我将保存序列化/ DeSerialization成本。正确错误？ III）在我的情况下实现Dispatcher Extensions也更好，因为当缓存逻辑在服务端时，为什么不必担心发生了哪个代理接口方法调用。正确/错误？
请建议我一个更好的解决方案，因为我想保存序列化/去磁化成本以及我想实现数据缓存。
提前致谢 / Rizwan
答案 0 :(得分：0)
我过去有两种方法可以合并WCF缓存：
使用Castle DynamicProxy为我的ServiceContract接口生成代理。这些动态代理使用拦截器来执行缓存。如果数据不在缓存中，则拦截器创建一个真实的WCF客户端（ChannelFactory<TInterface>）并调用WCF操作，然后缓存结果。我喜欢这种方法，因为缓存实现并不是特定于WCF的。
为WCF实现一个IRealProxy，它包装实际的远程操作并根据需要执行缓存/检索。原则上，这类似于方法1，但实现特定于WCF（具有.NET Remoting的残余）。我在迁移到＃1之前使用了这种方法。我迁移到方法1，因为方法1让我以实现无关的方式在客户端和服务器上完成缓存。当时，我推出了自己的RealProxy，但看起来其他人已经做了同样的事情并发布了代码：http://blog.ngommans.ca/index.php?/archives/31-Custom-Proxy-Generation-using-RealProxy.html