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，但非必须。

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