monorail是一个mvc模式的web框架, 它完全抛弃了传统的webform. 很多朋友都担心monorail会存在性能问题. 一个原因是它大量使用反射, 一个是它的velocity页面模板是解释执行(monorail有编译执行的brail模板引擎, 但是通常由于学习成本及它未及velocity成熟的因没有被采用). 当然webform复杂的生命周期, 控件结构及viewstate机制也是性能的瓶颈. 经过简单的测试, 总体来说monorail会比webform慢5%左右.
我感觉到更大的问题是monorail的官方并不支持页面级缓存. 页面缓存对互联网应用来说是很重要的, 因为网站读操作的频率要远远大于写, 而且还会不幸碰上无耻的爬虫和发广告软件的攻击. 我反编译了跟缓存相关的.net framework代码后, 发现它和webform完全无关, 管理页面缓存的System.Web.Caching.OutputCacheModule在HttpApplication的ResolveRequestCache事件中寻找是否有可用的缓存, 在UpdateRequestCache事件中检查当前HttpResponse的CachePolicy, 决定是否要把Response的内容缓存起来. 所以任何形式的asp.net应用程序都可以使用它, 只需要设置好当前的HttpResponse的CachePolicy. 在webform里页面缓存是作为预编译指令标记在aspx里, 在monorail中, 典型的的做法就是为controller编写一个facility, 然后通过自定义的Attribute去指定缓存相关的属性.
这个facility很简单: 定义一个的Attribute用来标记在controller和action上, 属性照搬@outputcache指令的参数Duration, Location, VaryByParam, VaryByHeader, VaryByCustom, 注册自己的contributor, inspector, 在inspector里根据Attribute的属性去设置HttpContext.Current.Response.Cache, 就这样ok了...
[PageCache]
public class HomeController : SmartDispatcherController
{
[PageCache(Duration = 30, VaryByParam = "*")]
public virtual void Index()
{
}
}
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。