宅男程序员给老婆的计算机课程之6:模版引擎

时间 2020-04-07

标签程序员老婆计算机课程模版引擎栏目快乐工作繁體版

原文原文链接

【51CTO独家特稿】设计模式再“高级”一点，即是所谓的“框架”了。css

从事Web开发，通常都会接触到MVC框架这个概念。html

M：也就是Model，直接跟网站数据库相关。前端

V：也就是View，是网页的模版，跟显示数据相关。程序员

C：则是Controller，至关于网站的业务逻辑。web

MVC也不只仅是应用于网站开发，它的概念实际上植根于桌面软件，而且在手机软件开发上也有应用。数据库

MVC自己是一个设计模式，是一个被验证过的，能够用来很好概括、管理代码的软件开发方式。c#

基于这样的设计模式，提供了不少相关的类库实现，则“设计模式”升级为“框架”。后端

MVC的任何一个方面，扩展出去讲，均可以讲上几天几夜。设计模式

今天只讲V。服务器

传统的ASP / PHP网站开发，V是很混乱的。

默认只有一种文件，html与业务逻辑代码混杂在同一个文件；至关难以维护。

ASP.NET相对于asp作出了很大改进，提出了code-behine的概念：默认将html的模版代码，以及c#或者vb.net的逻辑代码切分到两个不一样的文件。

这样的方式算是有很大进步。

微软平台上作开发是比较苦逼的，微软掌控了整个开发平台的前进速度。

asp跟PHP在开始的时候，是类似的技术。有相似的便利，以及相似的麻烦。

微软推出了.net，推广了code-behind的模式；而后，全部的微软程序员都超着微软指定的这个方向去迈进。

asp被抛弃了，自从ASP.NET诞生以后，就再也不有任何改进。

而PHP，在开源世界中，则不断的获得各式各样的改进。

各类模版引擎层出不穷；不只能够实现code-behind这样简单的模版、业务代码分割；不少还直接引入了MVC的概念；实现了三层的分割。

而ASP.NET，则长期止步于web form的code-behind，在开源世界中的MVC方案大放光彩若干年后，才推出 ASP.NET MVC。

模版技术，最初的目的就是要把业务代码，也就是说，把得到数据的代码跟html分割。

在模版实现上，所以涌现了很多不一样的设计哲学。

Python的Django框架中的模版，是一种典型。

它完全的禁止程序员在模版中嵌入任何代码；模版中，只能够出现html；以及一些跟业务逻辑无关的控制标签，如：

  
  
  
  
   
   
   
   {% If XXXX %} foo {% else %} bar {% end %}

条件XXXX，必须是一个数据值，不能够是一个复杂表达式、不能够包涵函数调用等等。

模版中，也不能够声明任何新的变量，下面的作法是被禁止的：

  
  
  
  
   
   
   
   {% set i = 0 %} 
   
   
   
   {% foreach item in items %} 
   
   
   
    {% i += 1%} 
   
   
   
    <div> 
   
   
   
    ` item ` 
   
   
   
    {% if i mod 2 == 0 %} 
   
   
   
    <hr /> 
   
   
   
    {% end %} 
   
   
   
    </div> 
   
   
   
   {% next %}

Django的模版，从技术上完全禁止程序员添加任何逻辑，强迫程序员必须在controller中去写各类逻辑，以确保模版内容的纯洁干净。

因此Django的模版，通常都很是简单，有很好的移植性，而且可让网页设计人员直接编辑。

ASP.NET则是另外一种典型；虽然有了code-behind，可是它没有对前端代码，以及后端代码作任何限制。

在前端aspx页面中，能够嵌入任意的逻辑代码，而code-behind的code，为空白；这种伪“code-behind”的方式，跟原来的asp没啥区别。

ASP.NET从框架自己，并不阻止程序员去作这样的事情，实际上，它还标榜它这样的特性：方便原有的asp项目直接升级到.NET的平台上。

也有另一种奇葩的作法，前端aspx页面保持空白，而后在code-behind的code中去拼接全部的html。这样的方式，ASP.NET框架自己也不由止。

只要ASP.NET程序员喜欢，没有什么不能够的。

ASP.NET把对模版使用方式的选择权留给了程序员，若是程序员自律，他们能够按Django模版那样的方式去使用模版，并拥有Django同样的优势；若是程序员自律？！

在某些能够经过嵌入代码去快速处理的场景，ASP.NET的模版也保留了程序员去hack的能力。

还有一些模版技术，则是折衷的（如tornado的模版）：容许嵌入单行代码，如声明变量，调用函数等等；可是不容许整块、整块的业务代码出现模版中。

上述三种模版设计哲学，各有它们的道理，以及应用场景。

须要根据具体的业务、应用场景，才能说其中哪一种比较合适。

开发人员的能力也是直接相关的，若是团队中，广泛不自律；缺少将业务、模版代码分割、以提升代码可维护性的意识，那么Django的作法是最好的，它直接禁止去滥用模版，强迫他们去使用更好的开发风格；即使在某些场景下会更麻烦。

武断的认为任何一种模版设计哲学是“最佳”的想法是极其肤浅的。

各类成熟的模版技术，通常也都会有包括如下特性：

1. 嵌入

也就是说，编写各类能够复用的小模版块，而后供多个不一样地方调用；比方说，用户头像（甚至名片）的显示。

具体页面不须要重复编写这些重复的模块。

而且，这些模块须要调整时，只须要修改一个地方，即可以在全部地方生效。

2. 继承

可以编写一些基础模版，定义常见的页面结构。

具体页面继承这些基础模版，便不须要重复编写那些结构代码。

一样的，当页面结构须要调整时，也是修改一处，全部生效。

3. i18n

网页模版的国际化支持是一个模版引擎是否成熟的表现。

若是没有，当网站须要同时提供多种不一样语言支持的时候，会很麻烦。

成熟的模版，都会提供内置的支持。

由于网页模版实现实在是太多了，你们功能也都差很少，那么性能，也就成为了至关重要的比较指标。

有的模版，可以“编译“，渲染起来快些。

通常能够简单认为，功能越多的模版，性能会约低。有的模版，甚至将i18n的支持变成可配置的，不须要的时候就能够关闭，以提升性能。

也有的模版认为，写 {% %} <%%> {{}} 这样的符号太麻烦了，能够直接忽略，它能够自动聪明的识别 html，以及模版控制代码。简单的说，就是以极其华丽的方式，去方面程序员少打几个字符。

还有的模版，在实现嵌入功能的时候，还能够选择所依赖的的css / js文件。

比方说，要显示用户的名片，须要引入 namecard.css；那么，能够在 namecard的模块文件中指定这个依赖，而后模版渲染的时候，自动把这个css的引用，放在html的头部。

直接在模块文件中写 namecard.css 的引用是很傻的，由于模块能够在模版中引用屡次。重复引用同一个css文件是没有道理的。

种种模版功能细节，实际上，都是能够在没有模版支持的框架中去实现。

想一想PHP，它原本是很是简单的，默认只可以在同一个文件中混杂逻辑与代码。

但一旦程序员有了追求，它也能够有模版实现。

模版不支持 i18n，程序员通常也是有办法在现有模版实现中添加相应的支持的。

并不复杂，关键是看程序员的态度；看程序员是否有把事情作得更好、更优雅的态度。

通常状况下，程序员选择去实现更多的模版功能的时候，必须先看看别人是怎么作的。比方说，若是彻底不知道什么是gettext就去自行实现模版的 i18n 功能，是很是2B的。

绝大多数状况下，程序员面临的问题，都不是本身独有的，必定是别人已经解决过的问题。

是否有足够的见识，有足够的知识广度，了解别人的解决一样问题的作法是程序员能力的表现。

是否有快速的搜索出相似的解决方案，也是能力的表现。

1. PHP的Smarty 模版的设计哲学是什么？

2. Perl的Mason 模版的设计哲学是什么？

3. 什么是gettext?

4. 前端Javascript实现的模版中，目前最成熟的是哪一个引擎？

男主角：Wuvist（新浪微博），真名翁伟，自称胖程序员一个，幸亏已婚。学习.NET出身，现经常使用Python作服务器端开发，曾任新加坡某创业公司主程。公司被Techcrunch blog事后，以为新加坡生活太过安逸，终于在去年辞职只身回家乡汕头创业，活跃于珠三角技术沙龙，热衷于与其余技术宅分享。

本文做者：Wuvist

女主角：Katze，Wuvist的老婆，女程序员，在某跨国投行任Unix系统管理员，常被Wuvist嘲笑技术太差。

51CTO系列：