淺談五大Python Web框架

Web開發者發表於2012-02-12

說到Web Framework,Ruby的世界Rails一統江湖,而Python則是一個百花齊放的世界,各種micro-framework、framework不可勝數,不完全列表見:

http://wiki.python.org/moin/WebFrameworks

雖然另一大指令碼語言PHP也有不少框架,但遠沒有Python這麼誇張,也正是因為Python Web Framework(Python Web開發框架,以下簡稱Python框架)太多,所以在Python社群總有關於Python框架孰優孰劣的話題,討論的時間跨度甚至長達3-5年。

Python這麼多框架,能挨個玩個遍的人不多,坦白的說我也只用過其中的三個開發過專案,另外一些稍微接觸過,所以這裡只能淺談一下,歡迎懂行的朋友們補充。

Django

Python框架雖然說是百花齊放,但仍然有那麼一家是最大的,它就是Django。要說Django是Python框架裡最好的,有人同意也有人 堅決反對,但說Django的文件最完善、市場佔有率最高、招聘職位最多估計大家都沒什麼意見。Django為人所稱道的地方主要有:

完美的文件,Django的成功,我覺得很大一部分原因要歸功於Django近乎完美的官方文件(包括Django book)。

全套的解決方案,Django象Rails一樣,提供全套的解決方案(full-stack framework + batteries included),基本要什麼有什麼(比如:cache、session、feed、orm、geo、auth),而且全部Django自己造,開發網 站應手的工具Django基本都給你做好了,因此開發效率是不用說的,出了問題也算好找,不在你的程式碼裡就在Django的原始碼裡。

強大的URL路由配置,Django讓你可以設計出非常優雅的URL,在Django裡你基本可以跟醜陋的GET引數說拜拜。

自助管理後臺,admin interface是Django裡比較吸引眼球的一項contrib,讓你幾乎不用寫一行程式碼就擁有一個完整的後臺管理介面。

而Django的缺點主要源自Django堅持自己造所有的輪子,整個系統相對封閉,Django最為人詬病的地方有:

系統緊耦合,如果你覺得Django內建的某項功能不是很好,想用喜歡的第三方庫來代替是很難的,比如下面將要說的ORM、Template。要在Django裡用SQLAlchemy或Mako幾乎是不可能,即使打了一些補丁用上了也會讓你覺得非常非常彆扭。

Django自帶的ORM遠不如SQLAlchemy強大,除了在Django這一畝三分地,SQLAlchemy是Python世界裡事實上的ORM標準,其它框架都支援SQLAlchemy了,唯獨Django仍然堅持自己的那一套。Django的開發人員對SQLAlchemy的支援也是有 過討論和嘗試的,不過最終還是放棄了,估計是代價太高且跟Django其它的模組很難合到一塊。

Template功能比較弱,不能插入Python程式碼,要寫複雜一點的邏輯需要另外用Python實現Tag或Filter。關於模板這一點,一直以來爭論比較多,最近有兩篇關於Python模板的比較有意思的文章可供參考:

  1. http://pydanny.blogspot.com/2010/12/stupid-template-languages.html(需翻牆)
  2. http://techspot.zzzeek.org/2010/12/04/in-response-to-stupid-template-languages/

URL配置雖然強大,但全部要手寫,這一點跟Rails的Convention over configuration的理念完全相左,高手和初識Django的人配出來的URL會有很大差異。

讓人糾結的auth模組,Django的auth跟其它模組結合緊密,功能也挺強的,就是做的有點過了,使用者的資料庫schema都給你定好了,這樣問題就來了,比如很多網站要求email地址唯一,可schema裡這個欄位的值不是唯一的,糾結是必須的了。

Python檔案做配置檔案,而不是更常見的ini、xml或yaml等形式。這本身不是什麼問題,可是因為理論上來說settings的值是能夠動態的改變的(雖然大家不會這麼幹),但這不是最佳實踐的體現。

總的來說,Django大包大攬,用它來快速開發一些Web運用是很不錯的。如果你順著Django的設計哲學來,你會覺得Django很好用,越用越順手;相反,你如果不能融入或接受Django的設計哲學,你用Django一定會很痛苦,趁早放棄的好。所以說在有些人眼裡Django無異於仙丹, 但對有一些人來說它又是毒藥且劇毒。

Pylons & TurboGears & repoze.bfg

除了Django另一個大頭就是Pylons了,因為TurboGears2.x是基於Pylons來做的,而repoze.bfg也已經併入Pylons project裡這個大的專案裡,後面不再單獨討論TurboGears和repoze.bfg了。

Pylons和Django的設計理念完全不同,Pylons本身只有兩千行左右的Python程式碼,不過它還附帶有一些幾乎就是Pylons御用 的第三方模組。Pylons只提供一個架子和可選方案,你可以根據自己的喜好自由的選擇Template、ORM、form、auth等元件,系統高度可 定製。我們常說Python是一個膠水語言(glue language),那麼我們完全可以說Pylons就是一個用膠水語言設計的膠水框架。

選擇Pylons多是選擇了它的自由,選擇了自由的同時也預示著你選擇了噩夢:

學習噩夢,Pylons依賴於許多第三方庫,它們並不是Pylons造,你學Pylons的同時還得學這些庫怎麼使用,關鍵有些時候你都不知道你 要學什麼。Pylons的學習曲線相對比Django要高的多,而之前Pylons的官方文件也一直是人批評的物件,好在後來出了The Definitive Guide to Pylons這本書,這一局面有所改觀。因為這個原因,Pylons一度被譽為只適合高手使用的Python框架。

除錯噩夢,因為牽涉到的模組多,一旦有錯誤發生就比較難定位問題處在哪裡。可能是你寫的程式的錯、也可能是Pylons出錯了、再或是SQLAlchemy出錯了、搞不好是formencode有bug,反正很凌亂了。這個只有用的很熟了才能解決這個問題。

升級噩夢,安裝Pylons大大小小共要安裝近20個Python模組,各有各自的版本號,要升級Pylons的版本,哪個模組出了不相容的問題都有可能,升級基本上很難很難。至今reddit的Pylons還停留在古董的0.9.6上,SQLAlchemy也還是0.5.3的版本,應該跟這條有關係。

Pylons和repoze.bfg的融合可能會催生下一個能挑戰Django地位的框架。

Tornado & web.py

Tornado即是一個Web server(對此本文不作詳述),同時又是一個類web.py的micro-framework,作為框架Tornado的思想主要來源於Web.py,大家在Web.py的網站首頁也可以看到Tornado的大佬Bret Taylor的這麼一段話(他這裡說的FriendFeed用的框架跟Tornado可以看作是一個東西):

“[web.py inspired the] Web framework we use at FriendFeed [and] the webapp framework that ships with App Engine…”

因為有這層關係,後面不再單獨討論Tornado。

Web.py的設計理念力求精簡(Keep it simple and powerful),總共就沒多少行程式碼,也不像Pylons那樣依賴大量的第三方模組,而是隻提供的一個框架所必須的一些東西,如:URL路由、 Template、資料庫訪問,其它的就交給使用者自己去做好了。

一個框架精簡的好處在於你可以聚焦在業務邏輯上,而不用太多的去關心框架本身或受框架的干擾,同時缺點也很明顯,許多事情你得自己操刀上。

我個人比較偏好這種精簡的框架,因為你很容易通過閱讀原始碼弄明白整個框架的工作機制,如果框架那一塊不是很合意的話,我完全可以Monkey patch一下按自己的要求來。

Bottle & Flask

Bottle和Flask作為新生一代Python框架的代表,挺有意思的是都採用了decorator的方式配置URL路由,如:

from bottle import route, run
 
@route('/:name')
def index(name='World'):
    return '<b>Hello %s!</b>' % name
 
run(host='localhost', port=8080)

Bottle、Flask跟web.py一樣,都非常精簡,Bottle甚至所有的程式碼都在那一個兩千來行的.py檔案裡。另外Flask和Pylons一樣,可以跟Jinja2、SQLAlchemy之類結合的很好。

不過目前不管是Bottle還是Flask成功案例都還很少。

Quixote

之所以要特別說一下Quixote,是因為國內的最大的用Python開發的網站“豆瓣網”是用Quixote開發的。我只簡單翻了一下原始碼,沒有做過研究,不發表評論,有經驗的來補充下。我只是在想,如果豆瓣網交到現在來開發,應該會有更多的選擇。

其它(web2py、uliweb、Karrigell、Werkzeug …)

最後關於框架選擇的誤區

在框架的選擇問題上,許多人很容易就陷入了下面兩個誤區中而不自知:

1. 哪個框架最好——世上沒有最好的框架,只有最適合你自己、最適合你的團隊的框架。程式語言選擇也是一個道理,你的團隊Python最熟就用Python好了,如果最熟悉的是Ruby那就用Ruby好了,程式語言、框架都只是工具,能多、快、好、省的幹完活就是好東西。

2. 過分關注效能——其實大部分人是沒必要太關心框架的效能的,因為你開發的網站根本就是個小站,能上1萬的IP的網站已經不多了,上10萬的更是很少很少。在沒有一定的訪問量前談效能其實是沒有多大意義的,因為你的CPU和記憶體一直就閒著呢。而且語言和框架一般也不會是效能瓶頸,效能問題最常出現在資料庫訪問和檔案讀寫上。 PHP的Zend Framework是出了名的慢,但是Zend Framework一樣有大站,如:digg.com;常被人說有效能問題的Ruby和Rails,不是照樣可以開發出twitter嗎?再者現在的硬 件、頻寬成本其實是很低的,特別有了雲端計算平臺後,人力成本才是最貴的,沒有上萬的IP根本就不用太在意效能問題,流量上去了花點錢買點伺服器空間好了, 簡單快速的解決效能問題。

注:前面有網友質疑我“Quora是用Pylons開發的”這樣的說法不客觀,特說明一下,這裡所說的某個網站A是用B開發的,只是指A主要或部分是由B開發的,大家就不要再去糾結A還用C了。

原文連結:http://feilong.me/2011/01/talk-about-python-web-framework

相關文章