相关疑难解决方法(0)

对于将在Web应用程序和富客户端应用程序中使用的.NET组件,似乎有两个明显的缓存选项:System.Web.Caching或Ent.库.缓存块.

• 你用什么？
• 为什么？

System.Web.Caching

在Web应用程序之外使用是否安全？我看到了混合信息,但我认为答案可能并非如此.

• 针对1.0和1.1非Web应用程序使用的KB文章警告
• 2.0页面有一个注释表明它没关系:http://msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspx
• 斯科特汉塞尔曼被这个概念所淹没
• 3.5页包含针对此类使用的警告
• Rob Howard 鼓励在网络应用之外使用

我不希望使用它的一个亮点,SqlCacheDependency,但在.NET 3.5中添加CacheItemUpdateCallback似乎是一件非常好的事情.

企业库缓存应用程序块

• 其他块已在使用中,因此依赖性已存在
• 缓存持久性不是必需的; 重启时重新生成缓存是可以的

某些缓存项应始终可用,但应定期刷新.对于这些项目,在删除项目后获取回调不是很方便.看起来客户端必须只是睡眠和轮询,直到重新填充缓存项.

Memcached for Win32 + .NET客户端

当您不需要分布式缓存时,有什么优缺点？

我们在ASP.NET中使用HttpRuntime.Cache API来缓存从数据库中检索的数据.

对于这个特定的应用程序,我们的数据库查询具有很多参数,所以我们的缓存键看起来像这样:

表表1 =;参数1 = somevalue1;参数2 = somevalue2;参数3 = somevalue3; param4 = somevalue4; param5 = somevalue5; param6 = somevalue6 ...等...

对于某些查询,我们有很多参数,缓存键长度为几百个字符.

我的问题:这些缓存键的长度是否有限制？在内部,它使用字典,因此从理论上讲,查找时间应该是不变的.但是,我想知道我们是否有可能遇到一些性能/内存问题.

我正在调查MVC3源并遇到以下(在OutputCacheAttribute.cs中),在生成用于输出缓存的键时调用它:

        // The key is typically too long to be useful, so we use a cryptographic hash
        // as the actual key (better randomization and key distribution, so small vary
        // values will generate dramtically different keys).
        using (SHA256 sha = SHA256.Create()) {
            return Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(uniqueIdBuilder.ToString())));
        }

评论说需要使用哈希,因为"密钥通常太长而无法使用".任何人都可以阐明这一点,并建议在asp.net中缓存键的最大长度？