我最近问了一个关于在ASP.NET MVC WebAPI应用程序中缓存应用程序数据的问题,它将我引向了一个新的问题。ASP.NET中可用的不同缓存方法的优缺点是什么?
我偶然发现:
http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx
私有静态状态供应商= null;
HttpContext.Current.Application"key“=”Value“
HttpRuntime.Cache.Insert( /* key */ "key",/* value */ "value",/*依赖*/ null,/* absoluteExpiration */ Cache.NoAbsoluteExpiration,/* slidingExpiration */ Cache.NoSlidingExpiration,/* priority */ CacheItemPriority.NotRemovable,/* onRemoveCallback */ null);
我相信还有其他的,而且我知道他们在技术上都将数据存储在memory...so中。你知道我应该用什么来做ASP.NET MVC webapi吗?
发布于 2013-09-22 12:09:21
每种缓存技术/方法都有自己的一组功能。这些特征在一个应用程序需求中似乎是不利的,但在其他应用程序需求中可能是有利的。
因此,简而言之,根据您的需求决定哪种缓存技术和哪些功能最适合您。
For example, Let us discuss some client side Caching techniques
__.
MSDN说,我们还可以使用HiddenField
在隐藏字段中仅存储少量频繁更改的数据,因为这些数据在每次回发时都包含在到服务器的往返中。
此功能的优势:使用客户端选项存储页面信息,从而减少了服务器上的工作负载。
然而,MSDN明确表示:这种方法具有最低限度的安全支持。
因此,可以使用也可以不使用此功能,因为安全方面的考虑也在那里。
Consider one more example
,Page Output caching
:有两种类型,页面输出缓存和页面分片缓存。
页面输出缓存缓存整个Web页面,只有当该页面的内容相当静态时才适用。如果页面的某些部分正在更改,则可以将静态部分包装为用户控件,并使用页面片段缓存来缓存用户控件。
And one last comment on
Application
vs HttpRuntime.cache
Application
不是缓存,它是一个全局命名值集合。如果你将一个对象添加到Application
中,它将一直保留到应用程序域回收。
application
Cache
:通过在Application
或Cache
类中缓存频繁请求的对象和数据,可以在ASP.NET应用程序中获得显着的性能改进。虽然Cache
类无疑提供了更大的灵活性和控制力,但在提高缓存吞吐量方面,与Application
类相比,它似乎只提供了一个边际优势。要开发一个测试方案来准确测量Cache
类通过清理过程对较少使用的对象进行内置管理的潜在优势是非常困难的,这与应用程序不提供此功能的事实相反。在这种情况下,开发人员需要做出决定,并且应该基于项目的需求和便利性及其使用模式。有关更多信息,请查看。
有关Asp.net中所有缓存技术的完整精彩解释,请参阅,并讨论每种技术的特性。
另外,这两个链接也是一个很好的资源:
发布于 2013-09-22 20:37:10
关于MemoryCache
和ASP.NET缓存:它们提供了非常相似的功能。在ASP.NET 4应用程序中,我通常更喜欢ASP.NET缓存,如果没有其他原因,那么是因为a bug in .NET 4,它显然在.NET 4.5中得到了修复。
静态字段适用于存储不需要过期策略的共享数据。
应用程序状态只不过是一个带有锁定语义的静态字典,它与经典ASP兼容--我使用它只是为了向后兼容遗留的经典ASP代码。
发布于 2013-09-22 20:27:12
在使用Web API时,缓存的首选应该始终是在HTTP响应中设置缓存头。HttpResponseMessage.CacheControlHeader
。
最后一个选项应该是任何依赖于HttpContext
或HttpRuntime
的选项,因为这会将您绑定到特定的主机。Web API应用程序应该独立于它们的主机构建。
https://stackoverflow.com/questions/18937855
复制相似问题