缓存数据并通知客户端ASP.NET中的数据更改

时间:2009-10-28 10:44:27

标签: asp.net caching notifications

我们正在考虑在我们的应用程序中进行一些架构更改,这可能会影响我们将因这些更改而使用的技术。

我在这篇文章中提到的变化是这样的:

我们发现应用程序的某些部分具有通用数据和公共服务,因此我们将这些部分提取到GlobalServices服务中,并使用自己的主数据db。 现在,这个服务可能有自己的缓存,因此它不必在每次调用时从数据库中检索数据。 因此,当一个客户端调用更新数据的服务时,其他客户端可能对该更改感兴趣。现在这取决于我们是否决定在客户端上保留缓存。

这意味着如果客户端将拥有自己的本地缓存,则必须以某种方式通知它们(并首先注册通知)。如果没有,他们将始终从GlobalServices服务获取数据。

我需要你的教育建议:

1) Is it a good idea to keep a local cache on the clients to begin with?
2) If we do decide to keep a local cache on the clients, would you use
   SqlCacheDependency to notify the clients, or would you use WCF for 
   notifications (each might have its cons and pros)

非常感谢大家,

阿维

1 个答案:

答案 0 :(得分:0)

我喜欢你的SqlCacheDependency的声音,但是我会从一个不同的角度回答这个问题,因为我和一个类似场景的团队一起工作过。我们创建了一个master数据库,并使用触发器创建在master中更改的数据的XML表示,并将其存储在TransactionQueue表中,其中包含一些关于更改内容,更改时间和更改者的元数据。客户端数据库会定期检查队列中是否有感兴趣的项目,并根据需要处理XML并更新自己的表。

我们也反过来为客户端更新主服务器。我们在客户端数据库上设置触发器和TransactionQueue表,以将数据发送回主服务器。这反过来会在下次轮询时更新所有其他客户端数据库。

关于这一点的好处是它在客户端平台和客户端数据结构上是相当不可知的,因此我们能够在一系列传统和第三方系统上使用该方法。另一个重要的一点是,您可以将任何数据库从循环中取出(包括主数据库 - 例如连接失败),其他数据库仍然可以正常工作。这对我们来说效果很好,因为我们的主数据库在我们的公司防火墙后面,而且更简单的网络数据库与我们的ISP坐在一起。

这种方法显然有缺点,比如种族危险,因此我们对事务处理,错误处理,重复数据删除等的顺序非常谨慎。我们还构建了一个管理GUI,以便在重要数据出现之前提供人工交互层。在主人身上发生了变化。

祝你好运!添