WCF/Silverlight/SQL数据库缓存策略

Question

好吧，我有一个非常复杂的Silverlight应用程序，它从一个WCF服务（asp.net托管的服务层）获取其数据，该服务又调用一个调用存储过程的数据层SQL 2005 DB来提取所需的数据。所以往返是这样的：

Silverlight应用程序 - > WCF服务 - >数据层 - >数据库 - >数据层 - > WCF服务将数据实体转换为相应的DTO（数据传输对象）或List <> - > Silverlight App

大部分数据都是高度关联的（所以它需要存在于数据库中），但它很少会改变。看起来我有几个位置选择来缓存这个“半常数”数据：

1. 我可以将其缓存在数据层中。我的数据层已经设置为使用SQLDependency类并缓存存储过程调用的结果。我认为这是或者可以是应用程序级缓存。
2. 我可以缓存在WCF服务本身的应用程序级别（或会话级别取决于调用）缓存结果的DTO。 （a）我甚至可以进一步通过将得到的DTO的XML序列化为WCF服务端的文件，以便我可以（a）检查内存缓存，然后（b）检查文件缓存和（c）击中数据层
3. 我可以在SL应用程序的客户端使用隔离存储来做类似于2（a）的操作。我可以使用散列（或者moddate或者其他）将数据序列化到本地隔离存储，然后只需拨打一个电话即可检查该数据。

还有一件事需要补充：我在IIS7中托管了这个WCF服务，并开启了动态压缩功能，以便（通常非常大且容易压缩的）XML响应得到gzip-ed。理想情况下，我想IIS会缓存这个gzip-ed结果以避免所有额外的处理。我认为它可能已经这样做了，但我不确定。

我很确定最终答案是“它取决于”的某种味道，但我很想听听别人如何接近这个。 Do X的一个好的战术方法，用工具Y测试性能，如果需要的话，做Z会很好。

几个环节（我会添加到这个，因为我研究这个）：

WCF Caching Approach

Answer 1

我认为＃2是可维护性和架构你最好的选择。 IIS提供缓存，为什么不使用它？

你不想从数据层引用System.Web。客户端也不是最好的选择，因为你必须编写一堆额外的代码来保持数据同步。

Answer 2

System.Web缓存在ASP.NET兼容模式下运行时是否可用于WCF？可能最好不要依赖它并写下你自己的。

另一方面，看看微软的Velocity项目，看起来它会产生一个非常有趣的缓存技术，而不依赖于ASP.NET。

Answer 3

如果您的用户数据变化非常少且需要快速响应，那么基于本地存储的自定义机制比等待服务器往返速度快得多。

Dino Sposito在MSDN杂志上发布了一篇有关本地存储和缓存的有趣文章，您可以找到捕获程序集的方法（想象一下只需加载所需的最小程序包，然后在后台的其余程序集中加载程序，性能火箭，你的代码更复杂:)）。

正如你所说的是事情要放在一个平衡和决定。

HTH 布劳

Answer 4

我的做法是这样的：

1. 确定是否确实存在具有性能问题
2. 衡量性能（是不是alreade接受我的用户？）在每个teir上（数据库提供数据需要多长时间？服务响应数据需要多长时间？从服务到客户端需要多长时间？）
3. 基于测量人员然后我会决定在哪里做我的缓存。请记住，缓存越接近数据存储，缓存越容易，但越接近您执行缓存的客户端，性能增益（通常）越好。

还要记住缓存不应该是改善性能的第一件事。您还应该考虑其他性能收益。存储过程是否缓慢？ WCF消息中有很多开销吗？服务中是否存在一些低效的处理？我真的需要在一条消息中使用所有这些数据吗？

HTH， 乔纳森

Answer 5

我们最近刚刚实施的＃3，使用独立存储客户端缓存。

在我们的应用程序中，我们有很多下拉菜单和自定义字段，每次载入时应用程序都会从​​服务器获取这些字段。将这些数据移至IS确实有帮助。该应用程序现在打电话来检查服务器上是否有任何更改，如果不是，则从IS加载数据，否则（很少）刷新IS。

这消除了大量的WCF调用和数据传输，SL页面的加载时间更短，并且由于减少了网络流量和数据库访问，应用程序通常变得更具可扩展性。

是的，涉及到一些编码，但对最终用户的好处是至关重要的。

安德鲁

Answer 6

如果使用RIA服务，然后进行简单的办法是有两个单独的EDMX定义。一个用于缓存实体，一个用于事务性实体。

一个域上下文可以通过AddReference see引用另一个domaincontext上的实体。

缓存的实体可以在用户认证后立即加载。为了简单起见，在缓存实体加载之前，事务数据不应该加载。

根据缓存的大小，您也可以考虑将这些值序列化到本地存储。