缓存代理设计建议

发布于 2024-07-27 21:11:45 字数 807 浏览 3 评论 0原文

我对代理比较陌生。
我目前需要为工作设计一个缓存代理。
我们有一个网络服务,它自然地根据对其的调用来提供数据。
我需要为富客户端应用程序创建一个代理来缓存这些调用的结果。
结果基本上是由 ids 组合标识的产品的字符串名称。

我可以创建一个类作为我的代理客户端,将结果缓存在缓存中,我正在考虑使用 System.Web.Caching.Cache 对象。

不过我想我应该问问是否有任何设计方面和考虑因素被我遗漏了。 有没有一种我没有发现的众所周知的设计?

[更新 - 2009 年 10 月 12 日]
似乎 System.Web.Caching.Cache 不建议用于客户端缓存。

http://msdn。 microsoft.com/en-us/library/system.web.caching.cache.aspx

Cache 类不适用于 在 ASP.NET 应用程序外部使用。 它的设计和测试用于 ASP.NET 为 Web 提供缓存 应用程序。 在其他类型的 应用程序,例如控制台 应用程序或 Windows 窗体 应用程序,ASP.NET 缓存可能 无法正常工作。

I'm relatively new to proxies.
I am currently required to design a caching proxy for work.
We have a webservice which serves up data based on calls to it, naturally.
I am required to create a proxy for a rich client application that caches the results of these calls.
The results are basically string names of products identified by a composition of ids.

I could just create a class that acts as my proxy client that caches the results in a cache, I was thinking of using the System.Web.Caching.Cache object.

However I thought I'd ask to see if there are any design aspects and considerations that I have missed. Is there a design that is commonly known that I have not found?

[UPDATE - 12 Oct 2009]
Seems like System.Web.Caching.Cache is not advisable for client side caching.

http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx:

The Cache class is not intended for
use outside of ASP.NET applications.
It was designed and tested for use in
ASP.NET to provide caching for Web
applications. In other types of
applications, such as console
applications or Windows Forms
applications, ASP.NET caching might
not work correctly.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

酷到爆炸 2024-08-03 21:11:45

首先,我在 Winforms 和 Service 解决方案中使用了 System.Web.Caching.Cache,并且从未遇到过问题。 我建议通过测试来缓解免责声明,以确保缓存正常工作并且不会泄漏资源,但我的测试都没有显示这种情况发生。

或者,企业库中有一个缓存解决方案,您可能还可以考虑一些其他开源解决方案。 如果您愿意的话,可能还有一些商业支持的。

但是,您是否在 ASP.Net 中托管 Web 服务(.asmx 扩​​展名通常是一个很好的指标)。 在这种情况下,您仍然使用 ASP.Net,因此免责声明不适用。

另请注意,ASP.Net 具有缓存选项,您可以直接从 web.config 驱动,而无需进行任何编码。

但以上都是服务器端缓存。

假设您的 Web 服务使用 HTTP(或 HTTPS)作为传输层,那么代理和客户端缓存需要使用 HTTP 响应标头,我认为涉及 Cache-Control、Expires 和可能的 Last-Modified。 然后由客户端和代理决定是否支持缓存。

或者,如果您实际上尝试编写一个支持缓存的代理解决方案(这将重写一个轮子,因此您应该有充分的理由这样做),那么您可能需要一个带有 System.Web.HttpRequest 和 System.Web.HttpRequest 的 HTTP 处理程序。 Web.HttpResponse 代表事物的客户端,并使用 System.Net.HttpWebRequest 和 System.Net.HttpResponse 将请求传递到服务器。 然后,System.Web.Caching.Cache 可以支持代理上的缓存响应。 也就是说,这里必须实现很多规则,包括 HTTP 请求标头(也有缓存控制选项)。

First, I've used System.Web.Caching.Cache in Winforms and Service solutions and never had a problem with it. I recommend mitigating against the disclaimer by testing to ensure the cache works and doesn't leak resources, but none of my testing ever showed this happening.

Alternatively there is a caching solution in Enterprise Library, and probably a bunch of other open source ones you could consider. And there are probably some commercially supported ones too if you prefer.

However, are you hosting your web service in ASP.Net (.asmx extension is usually a good indicator). In that case your still in ASP.Net and so the disclaimer shouldn't apply.

Also note that ASP.Net has caching options you can drive directly from the web.config without having to do any coding.

But all of the above is server side caching.

Assuming your web service is using HTTP (or HTTPS) as the transport layer, then proxy and client caching require use of the HTTP response headers, I think Cache-Control, Expires and possibly Last-Modified are involved. Then it is up to the client and proxies to decide whether they will support caching or not.

Alternatively if your actually trying to write a proxy solution that supports caching (and that would be rewriting a wheel so you should have a good reason to do this) then you probably want a HTTP Handler, with the System.Web.HttpRequest and System.Web.HttpResponse representing the client side of things, and passing the request through to the server using System.Net.HttpWebRequest and System.Net.HttpResponse. The System.Web.Caching.Cache could then support your cached responses on your proxy. That said there would be lots of rules to have to implement here, including HTTP Request headers (also has Cache-Control options).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文