上次我发了一个帖子，讨论了几种前端的实现方式，在此文中想针对模板方式进行一些补充。
其实说白了，这么多方式可以分为两类，一种是HTML在客户端组装，一种是HTML在服务端组装。
那么模板引擎也可以分成两类：
1） 客户端模板引擎，比如jtemplate。
在这里也有很多种实现方式：
- 模板在客户端，数据源通过ajax请求而来
- 模板和数据源都通过ajax请求而来
- 模板和数据源都在客户端（在生成页面的时候动态把数据嵌入进去）
这种方式的优点是数据和呈现（小部分不涉及安全的业务逻辑）很好得分离（ashx可以和html分不同的物理服务器放置），缺点是SEO支持不好。
如果模板和数据源都在客户端的话，性能会非常不错。
当然，一般大家都会把模板放在客户端（也是由服务器输出，或者可以说是模板是静态的），数据通过ajax请求获取。
2）服务端模板引擎。
对于这种方式，我想进一步扩展介绍各种实现方式：
- 运行时动态构建HTML的模板方式
运行时动态构建HTML的模板方式，就是在每一次请求的时候读取模板（可以在内存中缓存），然后为模板引擎（比如NVelocity）填充数据上下文，模板引擎按照规则把数据填充到HTML中去。
然后输出填充后的HTML，比如context.Put(“time”, DateTime.Now.ToSting()) ，为context的哈希表填充了一个键值对，这个值是固定的，就是一个时间点。
由于填充后的HTML的读者就是浏览器，而不会通过其它动态引擎构建，所以无法实现context.Put(“time”, “DateTime.Now.ToSting()”)，让time的值是一段服务端代码的执行结果。
这种方式的缺点是使用不是特别灵活，我们只能为上下文绑定固定的值。
- 结合Webform的编译时构建方式
比如，在编译的时候读取模板文件，然后把模板文件转换为输出服务端代码的ASPX文件，这个ASPX里面就是StringBuilder拼接的语句，其中静态的是HTML，而由于生成的是代码，所以内容其实是动态的代码，原理不多说了，参见此文。这种方式可以很好得和Webform结合使用，并且由于这个ASPX在编译时生成，生成出的代码又只是StringBuilder拼接，所以效率非常高，而且可以一样写CodeBehind（当然，不能操作控件）。由于其实生成的文件是ASPX（上面这种方式是从模板生成HTML，这种方式是从模板生成ASPX再通过Webform引擎生成HTML），所以可以使用Webform具有的很多其它特性（比如母板、用户控件、缓存）等等。
- 上述方式的改进-结合Webform的运行时构建方式
对上述方式的改动，利用ASP.NET 2.0 VirtualPathProvider特性在运行时通过模板生成ASPX文件。比上面一个方案好的是，很灵活，不需要编译（或手工调用重新生成方法），修改模板后自动生成ASPX，也可以做很多自动化的扩展。在这里可以下载示例代码。
