### 導航 - [索引](# "總目錄") - [下一頁](# "HTML/XHTML 常見問題") | - [上一頁](# "API") | - [Flask 0.10.1 文檔](#) ? # Flask 中的設計決策 如果你好奇 Flask 為什么用它的方式做事情，而不是別的方法，那么這節是為你準備的。這節應該給你一些設計決策的想法，也許起初是武斷且令人驚訝的，特別是直接與其它框架相比較。 ### 顯式的應用對象 一個基于 WSGI 的 Python web 應用必須有一個中央的可調用對象來實現實際的應用。在 Flask 中，這是一個 [Flask](# "flask.Flask") 類的實例。每個 Flask 應用必須創建一個該類的實例，并傳給它模塊的名稱，但是為什么 Flask 不自己這么做？ 當不是像下面的代碼這樣使用一個顯式的應用對象時: ~~~ from flask import Flask app = Flask(__name__) @app.route('/') def index(): return 'Hello World!' ~~~ 看起來會是這樣: ~~~ from hypothetical_flask import route @route('/') def index(): return 'Hello World!' ~~~ 這樣做有三個主要的原因。最重要的一個是，顯式的應用對象需要在同一時刻只存在一個實例。有許多方法來用單個應用對象來仿造多個應用，像維護一個應用的棧一樣，但這會導致一些問題，這里不會贅述。現在問題是：什么時候一個微框架在同一時刻需要至少一個應用？一個很好的例子是單元測試。當你想要測試什么的時候，創建一個最小化的應用來測試特定的行為非常有用。當應用對象刪除時，它分配的一切都會被再次釋放。 當你的代碼中有一個顯式的對象時，繼承基類（ [Flask](# "flask.Flask") ）來更改特定行為將成為可能。如果基于一個不暴露給你的類的對象在你之前創建，這么做只能通過 hack 。 此外， Flask 依賴于一個那個類的顯式實例還有一個非常重要的原因是：包名稱。無論何時你創建一個 Flask 實例，你通常傳給它 __name__ 作為包名。 Flask 依賴這個信息來正確地加載相對于你模塊的資源。在 Python 對反射的杰出支持下，它可以訪問包來找出模板和靜態文件存儲在哪（見 [open_resource()](# "flask.Flask.open_resource")）。當前顯然有許多框架不需要任何配置，且能載入相對于你應用的模塊的模板。但是它們需要為此使用當前工作目錄，一種非常不值得信賴的決定應用在哪的方式。當前工作目錄是進程間的，而且如果你想要在同一個進程中運行多個應用（這會在你不知道的一個 web 服務器中發生），路徑會斷開。更可怕的是：許多 web 服務器不把你應用的目錄，而是文檔根目錄設定為工作目錄，但兩者不一定是一個文件夾。 第三個原因是“顯明勝于隱含”。那個對象是你的 WSGI 應用，你不需要記住別的東西。如果你想要應用一個 WSGI 中間件，只需要封裝它（雖然有更好的方式來這么做來不丟失應用對象的引用 [wsgi_app()](# "flask.Flask.wsgi_app") ）。 此外，這個設計使得用工廠函數來創建應用成為可能，這對單元測試和類似的東西（ [*應用程序的工廠函數*](#) ）十分有用。 ### 路由系統 Flask 使用 Werkzeug 路由系統，其被設計為按復雜度自動為路由排序。這意味著，你可以任意順序聲明路由，而且他們仍會按期望工作。這在你想正確地實現基于裝飾器的路由是必須的，因為當應用被分割為多個模塊時裝飾器可以以未定義的順序調用。 另一個 Werkzeug 路由系統的設計決策是， Werkzeug 中的路由試圖確保 URL 是唯一的。 Werkzeug 對此會做的足夠多，因為它在路由不明確時自動重定向到一個規范的 URL 。 ### 某個模板引擎 Flask 在模板引擎上做了決定： Jinja2 。為什么 Flask 沒有一個即插的模板引擎接口？顯然，你可以使用一個不同的模板引擎，但是 Flask 仍然會為你配置Jinja2 。雖然 Jinja2 *總是* 配置的限制可能會消失，但綁定一個模板引擎并使用的決策不會。 模板引擎與編程語言類似，每個模板引擎都有特定的理解事物工作的方式。表面上，它們以相同方式工作：你給引擎一個變量的集合讓它為模板求值，并返回一個字符串。 然而，關于相同點的論述結束了。例如 Jinja2 有一個全面的過濾器系統，一個可靠的模板繼承方式，可以從模板內和 Python 代碼內使用復用塊（宏）的支持，對所有操作使用 Unicode，支持迭代模板渲染，可配置的語法等等。其它的引擎，一個類似Genshi——基于 XML 流求值的引擎，模板繼承要考慮 XPath 可用性等等。而 Mako 像對待 Python 模塊一樣處理模板。 當把一個模板引擎跟一個應用或框架聯系到一起，就不只是渲染模板了。比如，Flask 使用 Jinja2 全面的自動轉義支持。同樣，也提供了從 Jinja2 模板中訪問宏的途徑。 不去掉模板引擎的獨特特性的模板抽象層是一門對自身的科學，也是像 Flask的微框架的巨大事業。 此外，擴展也可以簡易地依賴于一個現有的模板語言。你可以簡單地使用你自己的模板語言，而擴展會始終依賴于 Jinja 本身。 ### 微與依賴 為什么 Flask 把自己叫做微框架，并且它依賴于兩個庫（也就是 Werkzeug 和Jinja 2）。為什么不能？如果我們仔細審查 Ruby 的 web 開發，有一個非常類似 WSGI 的協議。被稱作 Rack 的就是它，但是除此之外，它看起來非常像一個 WSGI 的 Ruby 實現。但是幾乎所有的 Ruby 應用不直接使用 Rack ，而是基于一個相同名字的庫。這個 Rack 庫與 Python 中的兩個庫不相伯仲： WebOb（以前叫 Paste ） 和 Werkzeug。 Paste 依然在使用，但是從我的理解，它有些過時，而贊同 WebOb 。 WebOb 和 Werzeug 的開發是一起開始的，也有著同樣的理念：為其它應用的利用做一個 WSGI 的良好實現。 Flask 是一個受益于 Werkzeug 妥善實現 WSGI 接口（有時是一個復雜的任務）既得成果的框架。感謝 Python 包基礎建設中近期的開發，包依賴不再是問題，并且只有很少的原因反對依賴其它庫的庫。 ### 線程局域變量 Flask 為請求、會話和一個額外對象（你可以在 [g](# "flask.g") 上放置自己的東西）使用線程局域對象（實際上是上下文局域對象，它們也支持 greenlet 上下文）。為什么是這樣，這不是一個壞主意嗎？ 是的，通常情況下使用線程局域變量不是一個明智的主意。它們在不基于線程概念的服務器上會導致問題，并且使得大型應用難以維護。但 Flask 不僅為大型應用或異步服務器設計。 Flask 想要使得編寫一個傳統 web 應用的過程快速而簡單。 一些關于基于 Flask 大型應用的靈感，見文檔的 [*聚沙成塔*](#) 一節。 ### Flask 是什么，不是什么？ Flask 永遠不會包含數據庫層，也不會有表單庫或是這個方向的其它東西。 Flask只建立 Werkezug 和 Jinja2 的橋梁，前者實現一個合適的 WSGI 應用，后者處理模板。 Flask 也綁定了一些通用的標準庫包，比如 logging 。其它所有一切取決于擴展。 為什么是這樣？眾口難調，因此 Flask 不強制把特異的偏好和需求囊括在核心里。大多數 web 應用都可以說需要一個模板引擎，但并不是每個應用都需要一個 SQL數據庫。 Flask 的思想是為所有應用建立一個良好的基礎，其余的一切都取決于你和擴展。 ? 版權所有 2013, Armin Ronacher.