客户端缓存C＃(Clientside Caching C#)

客户端缓存C＃(Clientside Caching C#)

我的wpf客户端在启动时从服务器加载了大量的常备数据。 所以，我想在客户端实现缓存策略。

我知道.NET框架中新的System.Runtime.Caching命名空间4.不幸的是，只有内存缓存。 我不希望在每次启动客户端时加载大量数据。 所以我正在寻找持久的客户端缓存。

你怎么看待这件事？

另一个想法是我使用OODB（如db4o或VelocityDB）进行客户端缓存。 这是一个坏主意吗？ 我没有客户端缓存方面的经验。

感谢您的回答和建议。

亲切的问候，亲

My wpf client is loading a lot of standing data at startup from the server. So, I want to implement a caching strategy at client side.

I know about the new System.Runtime.Caching namespace in the .NET framework 4. Unfortunately, there is only a memory caching. I don't want to load the huge amount of data at each startup of the client. So I'm searching for a persistent client caching.

What do you think about it?

Another idea was I use an OODB (like db4o or VelocityDB) for client caching. Is this a bad idea? I haven't any experience in client caching.

Thanks for your answers and suggestions.

Kind regards, pro

最满意答案

如何在客户端存储数据并不重要。 不过，我会考虑使用IsolatedStorage。 可能更难的是告诉缓存何时变为陈旧。 这实际上是System.Runtime.Caching所擅长的。 服务器数据是根本更改，还是仅在应用程序的新版本发生后更改？ 如果数据仅在新版本之后发生更改，您可能希望将其作为资源包含在应用程序设置中。 如果没有，您必须有一些超时或信号告诉客户端是时候检查服务器上的更改数据了。 您是否已经考虑过延迟加载数据？ 这样，延迟可能不会在应用程序启动时发生，并且不太明显，甚至可能您甚至不必将完整数据加载到客户端。

关于超时：在我们的应用程序中，我们有一个固定的超时，它在第一次加载时设置为每个引用列表，每次从缓存请求时，都会检查超时。 如果它已过期，则在返回列表之前透明地刷新缓存。 这是一种权衡，因为客户端的数据可能已经陈旧一段时间了。 我们接受这一点，因为它在我们的情况下并不重要，并且每个列表都负责自己，并且我们不需要中央注册表跟踪每个列表的状态以便从外部设置超时。

How you store the data on the client side doesn't matter very much. I'd look into IsolatedStorage for your purposes, though. What might be more difficult is to tell when the cache turns stale. This is actually what System.Runtime.Caching is good at. Does the server data change at all, or only after a new release of the application? If the data changes only after a new release, you might want to include it as resources into the application setup. If not, you'd have to have some timeout or signal which tells the client that it is time to check for changed data on the server. Have you already considered lazy loading of the data? That way, the delay would probably not occur all at application startup and would be less noticable, and probably you wouldn't even have to load the complete data into the client.

Regarding Timeouts: in our application, we have a fixed timeout which is set to each reference list when it is first loaded, and every time it is requested from the cache, that timeout is checked. If it has expired, the cache is transparently refreshed before the list is returned. This is a tradeoff, because the data on the client side could be stale for some time. We accept this, because it isn't critical in our case, and that way every list is responsible for itself and we don't need a central registry keeping track of each list's state in order to set the timeout from outside.