我們常用的web前端框架?其實(shí)簡(jiǎn)單稱呼叫web框架，現(xiàn)階段web前端技術(shù)成熟，從視覺體驗(yàn)到用戶體驗(yàn)都是比較好的，這也是從簡(jiǎn)單到復(fù)雜的web前端框架技術(shù)實(shí)現(xiàn)的，在國內(nèi)前端技術(shù)開發(fā)人員也是非常的多，市面上的前端框架可以說是眼花繚亂，這里寫這篇文章就是讓你在使用不同的前端框架?的時(shí)候能夠明確的知道自己的選擇。

Web前端框架工作原理：

在我們討論框架之前，我們需要理解Web如何“工作”的。為此，我們將深入挖掘你在瀏覽器里輸入一個(gè)URL按下Enter之后都發(fā)生了什么。在你的瀏覽器中打開一個(gè)新的標(biāo)簽，瀏覽http://www.uileader.com。我們討論為了顯示這個(gè)頁面，瀏覽器都做了什么事情（不關(guān)心DNS查詢）。

Web服務(wù)器

每個(gè)頁面都以HTML的形式傳送到你的瀏覽器中，HTML是一種瀏覽器用來描述頁面內(nèi)容和結(jié)構(gòu)的語言。那些負(fù)責(zé)發(fā)送HTML到瀏覽器的應(yīng)用稱之為“Web服務(wù)器”，會(huì)讓你迷惑的是，這些應(yīng)用運(yùn)行的機(jī)器通常也叫做web服務(wù)器。

然而，最重要的是要理解，到最后所有的web應(yīng)用要做的事情就是發(fā)送HTML到瀏覽器。不管應(yīng)用的邏輯多么復(fù)雜，最終的結(jié)果總是將HTML發(fā)送到瀏覽器（我故意將應(yīng)用可以響應(yīng)像JSON或者CSS等不同類型的數(shù)據(jù)忽略掉，因?yàn)樵诟拍钌鲜窍嗤模?/p>

HTTP

瀏覽器從web服務(wù)器（或者叫應(yīng)用服務(wù)器）上使用HTTP協(xié)議下載網(wǎng)站，HTTP協(xié)議是基于一種 請(qǐng)求-響應(yīng)（request-response）模型的。客戶端（你的瀏覽器）從運(yùn)行在物理機(jī)器上的web應(yīng)用請(qǐng)求數(shù)據(jù)，web應(yīng)用反過來對(duì)你的瀏覽器請(qǐng)求進(jìn)行響應(yīng)。

重要的一點(diǎn)是，要記住通信總是由客戶端（你的瀏覽器）發(fā)起的，服務(wù)器（也就是web服務(wù)器）沒有辦法創(chuàng)建一個(gè)鏈接，發(fā)送沒有經(jīng)過請(qǐng)求的數(shù)據(jù)給你的瀏覽器。如果你從web服務(wù)器上接收到數(shù)據(jù)，一定是因?yàn)槟愕臑g覽器顯示地發(fā)送了請(qǐng)求。

HTTP Methods

在HTTP協(xié)議中，每條報(bào)文都關(guān)聯(lián)方法（method或者verb），不同的HTTP方法對(duì)應(yīng)客戶端可以發(fā)送的邏輯上不同類型的請(qǐng)求，反過來也代表了客戶端的不同意圖。例如，請(qǐng)求一個(gè)web頁面的HTML，與提交一個(gè)表單在邏輯上是不同的，所以這兩種行為就需要使用不同的方法。

HTTP GET

GET方法就像其聽起來的那樣，從web服務(wù)器上get（請(qǐng)求）數(shù)據(jù)。GET請(qǐng)求是到目前位置最常見的一種HTTP請(qǐng)求，在一次GET請(qǐng)求過程中，web應(yīng)用對(duì)請(qǐng)求頁面的HTML進(jìn)行響應(yīng)之外，就不需要做任何事情了。特別的，web應(yīng)用在GET請(qǐng)求的結(jié)果中，不應(yīng)該改變應(yīng)用的狀態(tài)（比如，不能基于GET請(qǐng)求創(chuàng)建一個(gè)新帳號(hào)）。正是因?yàn)檫@個(gè)原因，GET請(qǐng)求通常認(rèn)為是“安全”的，因?yàn)樗麄儾粫?huì)導(dǎo)致應(yīng)用的改變。

HTTP POST

顯然，除了簡(jiǎn)單的查看頁面之外，應(yīng)該還有更多與網(wǎng)站進(jìn)行交互的操作。我們也能夠向應(yīng)用發(fā)送數(shù)據(jù)，例如通過表單。為了達(dá)到這樣的目的，就需要一種不同類型的請(qǐng)求方法：POST。POST請(qǐng)求通常攜帶由用戶輸入的數(shù)據(jù)，web應(yīng)用收到之后會(huì)產(chǎn)生一些行為。通過在表單里輸入你的信息登錄一個(gè)網(wǎng)站，就是POST表單的數(shù)據(jù)給web應(yīng)用的。

不同于GET請(qǐng)求，POST請(qǐng)求通常會(huì)導(dǎo)致應(yīng)用狀態(tài)的改變。在我們的例子中，當(dāng)表單POST之后，一個(gè)新的賬戶被創(chuàng)建。不同于GET請(qǐng)求，POST請(qǐng)求不總是生成一個(gè)新的HTML頁面發(fā)送到客戶端，而是客戶端使用響應(yīng)的響應(yīng)碼（response code）來決定對(duì)應(yīng)用的操作是否成功。

HTTTP Response Codes

通常來說，web服務(wù)器返回200的響應(yīng)碼，意思是，“我已經(jīng)完成了你要求我做的事情，一切都正?！?。響應(yīng)碼總是一個(gè)三位數(shù)字的代號(hào)，web應(yīng)用在每個(gè)響應(yīng)的同時(shí)都發(fā)送一個(gè)這樣的代號(hào)，表明給定的請(qǐng)求的結(jié)果。響應(yīng)碼200字面意思是“OK”，是響應(yīng)一個(gè)GET請(qǐng)求大多情況下都使用的代號(hào)。然而對(duì)于POST請(qǐng)求， 可能會(huì)有204（“No Content”）發(fā)送回來，意思是“一切都正常，但是我不準(zhǔn)備向你顯示任何東西”。

Web應(yīng)用

你可以僅僅使用HTTP GET和POST做很多事情。一個(gè)應(yīng)用程序負(fù)責(zé)去接收一個(gè)HTTP請(qǐng)求，同時(shí)給以HTTP響應(yīng)，通常包含了請(qǐng)求頁面的HTML。POST請(qǐng)求會(huì)引起web應(yīng)用做出一些行為，可能是往數(shù)據(jù)庫中添加一條記錄這樣的。還有很多其它的HTTP方法，但是我們目前只關(guān)注GET和POST。

那么最簡(jiǎn)單的web應(yīng)用是什么樣的呢？我們可以寫一個(gè)應(yīng)用，讓它一直監(jiān)聽80端口（著名的HTTP端口，幾乎所有HTTP都發(fā)送到這個(gè)端口上）。一旦它接收到等待的客戶端發(fā)送的請(qǐng)求連接，然后它就會(huì)回復(fù)一些簡(jiǎn)單的HTML。

下面是程序的代碼：

import socketHOST = ''PORT = 80listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)listen_socket.bind((HOST, PORT))listen_socket.listen(1)connection, address = listen_socket.accept()request = connection.recv(1024)connection.sendall(b"""HTTP/1.1 200 OKContent-type: text/html

（如果上面的代碼不工作，試著將PORT改為類似8080這樣的端口。）

這個(gè)代碼接收簡(jiǎn)單的鏈接和簡(jiǎn)單的請(qǐng)求，不管請(qǐng)求的URL是什么，它都會(huì)響應(yīng)HTTP 200（所以，這不是一個(gè)真正意義上的web服務(wù)器）。Content-type:text/html行代碼的是header字段，header用來提供請(qǐng)求或者響應(yīng)的元信息。這樣，我們就告訴了客戶端接下來的數(shù)據(jù)是HTML。

請(qǐng)求的剖析

如果看一下測(cè)試上面程序的HTTP請(qǐng)求，你會(huì)發(fā)現(xiàn)它和HTTP響應(yīng)非常類似。第一行 ，在這個(gè)例子中是GET / HTTP/1.0。第一行之后就是一些類似Accept: */*這樣的頭（意思是我們希望在響應(yīng)中接收任何內(nèi)容）。

我們響應(yīng)和請(qǐng)求有著類似的第一行，格式是 ，在外面的例子中是HTTP/1.1 200 OK。接下來是頭部，與請(qǐng)求的頭部有著相同的格式。最后是響應(yīng)的實(shí)際包含的內(nèi)容。注意，這會(huì)被解釋為一個(gè)字符串或者二進(jìn)制文件，Content-type頭告訴客戶端怎樣去解釋響應(yīng)。

解決路由和模板兩大問題

圍繞建立web應(yīng)用的所有問題中，兩個(gè)問題尤其突出：

1.我們?nèi)绾螌⒄?qǐng)求的URL映射到處理它的代碼上？

2.我們?cè)鯓觿?dòng)態(tài)地構(gòu)造請(qǐng)求的HTML返回給客戶端，HTML中帶有計(jì)算得到的值或者從數(shù)據(jù)庫中取出來的信息？

每個(gè)web框架都以某種方法來解決這些問題，也有很多不同的解決方案。用例子來說明更容易理解，所以我將針對(duì)這些問題討論Django和Flask的解決方案。但是，首先我們還需要簡(jiǎn)單討論一下MVC。

Django中的MVC

Django充分利用MVC設(shè)計(jì)模式。MVC，也就是Model-View-Controller（模型-視圖-控制器），是一種將應(yīng)用的不同功能從邏輯上劃分開。models代表的是類似數(shù)據(jù)庫表的資源（與Python中用class來對(duì)真實(shí)世界目標(biāo)建模使用的方法大體相同）。controls包括應(yīng)用的業(yè)務(wù)邏輯，對(duì)models進(jìn)行操作。為了動(dòng)態(tài)生成代表頁面的HTML，需要views給出所有要?jiǎng)討B(tài)生成頁面的HTML的信息。

在Django中有點(diǎn)讓人困惑的是，controllers被稱做views，而views被稱為templates。除了名字上的有點(diǎn)奇怪，Django很好地實(shí)現(xiàn)了MVC的體系架構(gòu)。

Django中的路由

路由是處理請(qǐng)求URL到負(fù)責(zé)生成相關(guān)的HTML的代碼之間映射的過程。在簡(jiǎn)單的情形下，所有的請(qǐng)求都是有相同的代碼來處理（就像我們之前的例子那樣）。變得稍微復(fù)雜一點(diǎn)，每個(gè)URL對(duì)應(yīng)一個(gè)view function。舉例來說，如果請(qǐng)求www.foo.com/bar這樣的URL，調(diào)用handler_bar()這樣的函數(shù)來產(chǎn)生響應(yīng)。我們可以建立這樣的映射表，枚舉出我們應(yīng)用支持的所有URL與它們相關(guān)的函數(shù)。

然而，當(dāng)URL中包含有用的數(shù)據(jù)，例如資源的ID（像這樣www.foo.com/users/3/） ，那么這種方法將變得非常臃腫。我們?nèi)绾螌RL映射到一個(gè)view函數(shù)，同時(shí)如何利用我們想顯示ID為3的用戶？

Django的答案是，將URL正則表達(dá)式映射到可以帶參數(shù)的view函數(shù)。例如，我假設(shè)匹配^/users/(?P\d+)/$的URL調(diào)用display_user(id)這樣的函數(shù)，這兒參數(shù)id是正則表達(dá)式中匹配的id。這種方法，任何/users//這樣的URL都會(huì)映射到display_user函數(shù)。這些正則表達(dá)式可以非常復(fù)雜，包含關(guān)鍵字和參數(shù)。

Flask中的路由

Flask采取了一點(diǎn)不同的方法。將一個(gè)函數(shù)和請(qǐng)求的URL關(guān)聯(lián)起來的標(biāo)準(zhǔn)方法是通過使用route()裝飾器。下面是Flask代碼，在功能上和上面正則表達(dá)式方法相同：

@app.route('/users//')

def display_user(id):

# ...

就像你看到的這樣，裝飾器使用幾乎最簡(jiǎn)單的正則表達(dá)式的形式來將URL映射到參數(shù)。通過傳遞給route()的URL中包含的指令，可以提取到參數(shù)。路由像/info/about_us.html這樣的靜態(tài)URL，可以像你預(yù)想的這樣@app.route('/info/about_us.html')處理。

通過Templates產(chǎn)生HTML

繼續(xù)上面的例子，一旦我們有合適的代碼映射到正確的URL，我們?nèi)绾蝿?dòng)態(tài)生成HTML？對(duì)于Django和Flask，答案都是通過HTML Templating。

HTML Templating和使用str.format()類似：需要?jiǎng)討B(tài)輸出值的地方使用占位符填充，這些占位符后來通過str.format()函數(shù)用參數(shù)替換掉。想象一下，整個(gè)web頁面就是一個(gè)字符串，用括號(hào)標(biāo)明動(dòng)態(tài)數(shù)據(jù)的位置，最后再調(diào)用str.format()。Django模板和Flask使用的模板引擎Jinja2都使用的是這種方法。

然而，不是所有的模板引擎都能相同的功能。Django支持在模板里基本的編程，而Jinja2只能讓你執(zhí)行特定的代碼（不是真正意義上的代碼，但也差不多）。Jinja2可以緩存渲染之后的模板，讓接下來具有相同參數(shù)的請(qǐng)求可以直接從緩存中返回結(jié)果，而不是用再次花大力氣渲染。

數(shù)據(jù)庫交互

Django有著“功能齊全”的設(shè)計(jì)哲學(xué)，其中包含了一個(gè)ORM(Object Realational Mapper，對(duì)象關(guān)系映射)，ORM的目的有兩方面：一是將Python的class與數(shù)據(jù)庫表建立映射，而是剝離出不同數(shù)據(jù)庫引擎直接的差異。沒人喜歡ORM，因?yàn)樵诓煌挠蛑g映射永遠(yuǎn)不完美，然而這還在承受范圍之內(nèi)。Django是功能齊全的，而Flask是一個(gè)微框架，不包括ORM，盡管它對(duì)SQLAlchemy兼容性非常好，SQLAlchemy是Django ORM的最大也是唯一的競(jìng)爭(zhēng)對(duì)手。

內(nèi)嵌ORM讓Django有能力創(chuàng)建一個(gè)功能豐富的CRUD應(yīng)用，從服務(wù)器端角度來看，CRUD（CreateRead Update Delete）應(yīng)用非常適合使用web框架技術(shù)。Django和Flask-SQLchemy可以直接對(duì)每個(gè)model進(jìn)行不同的CRUD操作。

總結(jié)：

到現(xiàn)在為止，web前端框架的目的應(yīng)該非常清晰了：向程序員隱藏了處理HTTP請(qǐng)求和響應(yīng)相關(guān)的基礎(chǔ)代碼。至于隱藏多少這取決于不同的框架，Django和Flask走向了兩個(gè)極端：Django包括了每種情形，幾乎成了它致命的一點(diǎn)；Flask立足于“微框架”，僅僅實(shí)現(xiàn)web應(yīng)用需要的最小功能，其它的不常用的web框架任務(wù)交由第三方庫來完成。

但是最后要記住的是，Python web框架都以相同的方式工作的：它們接收HTTP請(qǐng)求，分派代碼，產(chǎn)生HTML，創(chuàng)建帶有內(nèi)容的HTTP響應(yīng)。事實(shí)上，所有主流的服務(wù)器端框架都以這種方式工作的（JavaScript框架除外）。但愿了解了這些框架的目的，你能夠在不同的框架之間選擇適合你應(yīng)用的框架進(jìn)行開發(fā)。