我已经组建了一个小的ASP.NET MVC 2站点,它可以进行一些非常广泛的日期挖掘/表连接/等.
使用MVC,我有一个控制器,以许多不同的形式(表,图像等)返回数据.为了节省频繁访问数据库,我有一个双缓存机制：
>对于相同操作的相同参数,我使用OutputCacheAttribute和VaryByParam =“*”.
>假设动作的某些参数已经改变(或者调用了另一个动作),我的“数据”仍然可能先前被请求了,所以我在数据库第一次命中后将数据存储在视图模型中,我实现了这与.NET 4.0 System.Runtime.Caching.ObjectCache.
Controller内部的ObjectCache示例：
private static readonly ObjectCache cache =
new MemoryCache("CompareControllerCache");
private static void CacheObject(viewmodel obj,string param1,int someOtherParam )
{
string key = string.Format("{0}-{1}",param1,someOtherParam);
Trace.WriteLine(string.Format("Adding {0} to the cache",key));
cache.Add(key,obj,new CacheItemPolicy
{
SlidingExpiration = TimeSpan.FromMinutes(1)
});
}
// Corresponding GetCachedObject with similar key defining logic.
这给了我一个很好的性能改进,但失败的地方就是CacheItemPolicy非常简单.理想情况下,我希望缓存窗口更大,但如果数据库发生更改,缓存项目将会过期.
CacheItemPolicy似乎支持使用ChangeMonitors集合,我可以添加一个sqlChangeMonitor,但是当我尝试构建它时,我就停止了.
我正在使用Entity Framework 4访问sql数据库,如何构建sqlChangeMonitor来监视可能触发缓存过期的几个数据库表？
sqlChangeMonitor是用sqlDependency构造的,它采用sqlCommand – 如何锁定Entity Framework对数据库的封装？
解决方法
可以在sqlDependency中包装任意LINQ查询,包括EF Linq查询,参见
LinqToCache.但不幸的是,EF选择为查询制定sql的方式,即使是最简单的from context.table select t,也是不兼容的使用Query Notificaiton限制,sqlDependency立即作为无效语句失效.我在
SqlDependency based caching of LINQ Queries年已经谈过这个问题.
您可以做的是使用sqlChangeMonitor和简单的sqlCommand对象,这些对象构造为可能更改的表上的简单SELECT … FROM Table.您需要了解在设置通知的成本和轮询成本之间存在平衡,如果您的表经常更改,那么监视更改可能会比轮询更昂贵.请参阅文章The Mysterious Notification以了解QN的工作原理以及监控成本.
