卓越之行

皓月碧空,漫野如洗,行往卓越的路上

Razor视图引擎浅析

从Web Form开始,视图的机制其实就没改变过,动态编译视图脚本。所不同的是,Razor就仅仅是模板,没在嵌入与网站等相关的东西,应该是SRP的一个体现。

可惜,这种功能分离仍做得不彻底,MVC中,Razor与其他部分的整合仍比较多,路径的寻找等功能的嵌入,使得它不容易单独拿出来使用。当然,这也是微软的一贯风格,整体使用性能优先。视图引擎浅析


模板是其最主要的功能,但是另一个次功能也不可忽视,内嵌帮助方法及其智能代码完成功能。这个附助功能,大大提高效能。

现在,我们面临的问题是,当脱离ASP。Net MVC的框架以后,如何保持这个特性。幸运的是,微软提供了扩展的接口或者说方法。

在阐述解决方案之前,还是再回顾一下视图引擎的原理。
从Web Form到Razor,即有继承也有扬弃。模板文件(cshtml vbhtml),仍然是当作一个类来处理,这与原来的机制是一致,不同的是不再是静态类,以前文件名就是页面类名,并且还可以有一个真正的类文件直接使用(code behind, partial class)。而Razor是完全的运行时编译生成的类,甚至类名都是临时生成Guid。
所有这些改变,使得对View的控制如同要抓住随风漂动的树叶,几乎不可能,幸运的是,漂动叶子有着不动的根,这个根就是所有View的基类,WebViewPage。注意到这个类是个抽象类,原因显而易见。
抓到这个根本之后,MVC的很多特性和功能就立马找到了出处。
比如,HtmIHelper(Razor 使用@Html), Model (Razor 使用@Model)等,其实都是这个基类的一个属性。

以上就是Razor视图的主要的机制,如果开发人员只使用ASPNet MVC本身的功能,而不去扩展,或者像我们一样完全创建一套自己全新的框架,那么这些背后的故事,知道也可,不了解也无所谓。

而对我们的框架开发来说,还有一个重要问题,扩展接口在哪里?答案却是极其简单,在Web,Config文件有一块<pages>的配置区或,其中有一项ParseBaseType改成你自己View的基类即可。甚至,代码智能提示(IntelliSense)功能就马上起作用(也许要重起Visual Studio)。这个自定义类可以继承自WebViewPage,但非必须。

好了,万事俱备,可以开始展开你想象翅膀,做你想作的事了。


阅读更多
个人分类: C# Asp.Net Razor
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭