片段缓存的实际应用、延迟加载及Eazy类库
2009-09-22 14:54 by 老赵, 14155 visits片段缓存(二,三)已经实现完整了,但好像还没有提到如何在项目中进行实际应用,那么现在就来谈一谈这方面。之前也有朋友提出,这个片段缓存到底省下的是什么啊?好像数据都是在Controller中获取的,视图的生成不会带来多少开销啊,难道节省的只是拼接HTML字符串的时间吗?这其实就涉及到片段缓存在实际项目中该如何使用的问题了。
上周日的幻灯片中我提到Ruby on Rails中的Fragment Caching一般是这样使用的:
class BlogController < ApplicationController def list unless read_fragment(:action => 'list' ) @articles = Article.find_recent end end end
以及它的视图模板:
<% cache do %> <!- Here's the content we cache -> <ul> <% for article in @articles -%> <li><p><%= h(article.body) %></p> <% end -%> </li></ul> <% end %>
以上是一个Controller和一个名为list的Action方法,再list方法中回去检查片段缓存是否存在,如果不存在才去加载@articles字段。视图模板中的逻辑也类似,如果缓存不存在才去访问@article字段。这样,读取@acticle的开销便节省下来了。在我之前公布的ASP.NET MVC片段缓存实现中,还无法在Controller中操作缓存,近期打算加上这方面的功能。
可是这样的做法可能会产生一个问题:在并发情况高的环境下,可能视图会访问到没有初始化的@articles字段。因为在Action方法中缓存还没有过期,但是就在正式生成视图内容,缓存过期了——于是就引起了错误。不过,其实我在想到“片段缓存”时,第一反应并不是这种做法,而是使用“延迟加载”。
使用延迟加载,也就是说在Action方法中虽然不会加载某个字段,但是还是会给这个字段“打一个桩(stub)”。如果视图中不妨问这个字段自然无妨,但在需要访问的话,也可以正常获取到数据。于是这种做法既可以省下开销,又不会出现问题。
不过使用延迟加载并非完全没有代价,它要求资源回收的时机不能太早。据我所知,有些朋友会使用Action Filter,在OnActionExecuted时回收所有资源(如数据库连接),这样在视图中自然无法获取数据了。因此,如果您使用延迟加载,请务必在OnResultExecuted时回收资源。
那么,我们该如何使用延迟加载呢?最容易的做法自然是稍微修改一下你的Model,保持接口不变即可。不过现在您也可以关注一下Eazy类库。
Eazy类库是我前一段时间设想中的“延迟辅助类库”,名字来源于Easy + Lazy,目前托管在CodePlex中。有了这个类库的帮助,您就无需对自己的类库“小动干戈”了。于是,您就可以在Action方法使用这样的代码来设置字段的延迟功能:
public ActionResult List() { var model = LazyBuilder.Create<Model>() .Setup(m => m.Articles, () => Article.FindRecent()) .Instance; return View(model); }
LazyBuilder.Create方法会创建Model类型的实例,然后使用Setup方法可以为某个属性指定一个委托,而这个委托便会在第一次访问这个属性时执行。LazyBuilder的实现机制非常清晰,只是使用Emit在运行时动态创建目标类型的子类而已。例如Model类型:
public class Model { public virtual List<Article> Articles { get; set; } }
便会为它生成如下的子类:
public class Model$LazyProxy : Model { public override List<Article> Articles { get { if (this.Articles$LazyLoader != null) { base.Articles = this.Articles$LazyLoader(); this.Articles$LazyLoader = null; } return base.Articles; } set { base.Articles = value; this.Articles$LazyLoader = null; } } public Func<List<Article>> Articles$LazyLoader = null; }
这段写法是我认为实现延迟加载最理想的方式了,最重要的是它保留了属性原有的逻辑,只是在加载时机上做了文章。此外,在不需要延迟加载的情况下,属性的行为也不会改变。
不过Eazy项目其实才创建了2天,目前只能通过指定泛型类型来构造对象,这意味着这个类型必须有默认的构造函数。根据我的设想,它以后还会支持其他的构造方式,例如:
var builder = LazyBuilder.Create(() => new Model(1, 2) { Time = DateTime.Now }); builder.Setup(m => m.Articles, () => Article.FindRecent()); var model = builder.Instance;
由于完全使用Emit,因此不会带来反射的开销,性能是很有保障的。例如LazyBuilder.Create<Model>的消耗和new Model()相比也就是多了些方法调用而已。目前Eazy项目还比较简陋,例如代码中不会抛出恰当的异常,单元测试也不够完整。此外,我还在考虑是否要对只读属性或接口提供延迟加载的支持。
当然,如果您有什么想法也请告诉我,这里先谢过了。
昨天关心的问题,今天有了全面方案了。呵呵。