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

【问题标题】：WCF/Silverlight/SQL DB Caching StrategiesWCF/Silverlight/SQL 数据库缓存策略
【发布时间】：2012-05-09 00:18:09
【问题描述】：

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

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

大部分数据是高度相关的（因此它需要存在于数据库中），但不会经常更改。似乎我有几种位置可以缓存这个“半常数”数据：

我可以在数据层缓存它。我的数据层已经设置为使用 SQLDependency 类并缓存存储过程调用的结果。我认为这是或可以是应用程序级缓存。
我可以在 WCF 服务本身的应用程序级别（或会话级别，取决于调用）缓存中缓存生成的 DTO。 2(a) 我什至可以更进一步，将生成的 DTO 的 XML 序列化到 WCF 服务端的文件中，以便我可以 (a) 检查内存缓存，然后 (b) 检查文件缓存和(c) 命中数据层
我可以在 SL 应用程序的客户端使用隔离存储来执行类似于 2(a) 的操作。我可以使用哈希（或 moddate 或其他东西）将数据序列化到本地隔离存储，然后调用来检查。

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

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

一些链接（我会在研究时添加）：

【问题讨论】：

【解决方案1】：

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

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

正如你所说，重要的是要平衡并做出决定。

HTH 布劳略

【讨论】：

【解决方案2】：

我的方法是这样的：

还请记住，缓存不应该是提高性能的第一件事。您还应该研究其他性能提升。存储过程慢吗？ WCF 消息中是否有很多开销？服务中是否存在一些低效的处理？我真的需要一条消息中的所有数据吗？

HTH, 乔纳森

【讨论】：

【解决方案3】：

我认为#2 是可维护性和架构的最佳选择。 IIS提供缓存，为什么不用呢？

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

【讨论】：

【解决方案4】：

当 WCF 未在 ASP.NET 兼容模式下运行时，它是否可以使用 System.Web 缓存？可能最好不要依赖它并自己编写。

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

【讨论】：

【解决方案5】：

我们最近刚刚实现了 #3，即使用独立存储的客户端缓存。

在我们的应用程序中，我们有很多下拉菜单和自定义字段，应用程序每次加载时都会从服务器获取这些字段。将这些数据转移到 IS 确实很有帮助。该应用程序现在调用以检查服务器上是否有任何更改，如果没有 - 从 IS 加载数据，否则（这是非常罕见的）刷新 IS。

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

是的，这涉及到一些编码，但最终用户的利益是必不可少的。

安德鲁

【讨论】：

【解决方案6】：

如果您使用 RIA 服务，那么一个简单的方法是拥有两个单独的 edmx 定义。一种用于缓存实体，一种用于事务性实体。

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

缓存的实体可以在用户通过身份验证后立即加载。为简单起见，在缓存实体加载之前，不应加载事务数据。

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

【讨论】：