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

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

我在这篇文章中提到的变化如下：

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

这意味着，如果客户端将拥有自己的本地缓存，则必须以某种方式通知它们（并首先注册通知）。如果没有，他们将始终从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)

谢谢大家

---

Avi

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

我们也做了同样的相反的客户端更新主。我们在客户机数据库上设置触发器和TransactionQueue表，以将数据发送回主机。这反过来会在下次轮询时更新所有其他客户端数据库

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

这种方法有明显的缺点，比如竞争风险，因此我们对事务处理、错误处理、重复数据消除等的顺序非常小心。我们还构建了一个管理GUI，在主数据中的重要数据更改之前提供了一个人机交互层

---

祝你好运！Tim

嗯，这听起来很有趣，也很复杂，这是一个只有dba才能提供的解决方案：）恐怕我们这家刚刚起步的公司还不具备这方面的知识。我个人并不喜欢在数据库中加入太多的逻辑。但是如果它对你有用的话，那就太好了，知道这样一种工作方式很好。谢谢蒂姆！