宅男程序員給老婆的計算機課程之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事後，以爲新加坡生活太過安逸，終於在去年辭職隻身回家鄉汕頭創業，活躍於珠三角技術沙龍，熱衷於與其餘技術宅分享。