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

Question

好的，我有一个非常复杂的 silverlight 应用程序，它从 WCF 服务(asp.net 托管服务层)获取数据，该服务又调用一个数据层，该数据层调用 SQL 2005 数据库中的存储过程以提取所需的数据.所以往返是这样的:

Silverlight App --> WCF Service --> Data Layer --> DB --> Data Layer --> WCF Service将Data Entity转换为对应的DTO(Data Transfer Object)或List<> --> Silverlight App

很多数据都是高度相关的(因此它需要存在于数据库中)，但它们很少会发生变化。似乎我有几个位置选择来缓存这个“半恒定”数据:

1. 我可以将它缓存在数据层中。我的数据层已设置为使用 SQLDependency 类并缓存存储过程调用的结果。我认为这是或可以是应用程序级缓存。
2. 我可以将生成的 DTO 缓存在 WCF 服务本身的应用程序级别(或 session 级别，具体取决于调用)缓存中。2(a) 我什至可以更进一步，将生成的 DTO(s) 的 XML 序列化到 WCF 服务端的一个文件中，这样我就可以 (a) 检查内存缓存，然后 (b) 检查文件缓存和(c) 命中数据层
3. 我可以在 SL 应用程序的客户端执行类似于 2(a) 的独立存储。我可以使用哈希(或 moddate 之类的东西)将数据序列化到本地隔离存储，然后调用来检查。

还有一件事要补充:我在 IIS7 中托管此 WCF 服务并启用了动态压缩，以便(通常非常大且易于压缩)XML 响应得到 gzip 压缩。理想情况下，我似乎希望 IIS 缓存此 gzip 压缩结果以避免所有额外处理。我认为它可能已经这样做了，但我不确定。

我很确定这个问题的最终答案有点“视情况而定”，但我很想听听其他人是如何处理这个问题的。 Do X 的良好战术配方，使用工具 Y 测试性能，如果需要的话，do Z 会很棒。

几个链接(我会在研究这个的时候添加到这个):

WCF Caching Approach

Answer 1

如果您的用户数据很少更改并且需要快速响应，那么采用基于本地存储的自定义机制比等待服务器往返要快得多是一个很大的优势。

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

正如您所说，权衡利弊再做决定。

HTH 布劳略