1、blueprint
在使用flask進行一個項目編寫的時候，可能會有許多個子產品，如一個普通的網際網路sass雲辦公應用，會有使用者管理、部門管理、賬号管理等子產品，如果把所有的這些子產品都放在一個views.py檔案之中，那麼最後views.py檔案必然臃腫不堪，并且極難維護，是以flask中便有了blueprint的概念，可以分别定義子產品的視圖、模闆、視圖等等，我們可以使用blueprint進行不同子產品的編寫，不同子產品之間有着不同的靜态檔案、模闆檔案、view檔案，十分友善代碼的維護和管理，下面就是使用blueprint來進行上面使用者管理、部門管理、賬号管理子產品的模拟編寫，隻涉及到api層面上，模闆檔案和靜态檔案就不寫在上面了。
2、分子產品後的結構
在進行分子產品編寫接口之後，以前提供的接口就不能寫在一個views.py檔案之中，具體結構如下所示：
dept: 這是部門管理子產品，views是相應的接口檔案。
user: 這是使用者管理子產品，同上，views是使用者管理的相應接口。
其他的和之前的類似。
3、業務子產品
3.1 dept子產品
在這裡，我們定義了dept blueprint對象，便于在views.py檔案中應用，替代Flask對象。主要的接口
views.py:
提供兩個接口，一個接口用于查詢特定的部門，一個接口用于傳回部門清單，dept對象我是模拟的部門數組，沒有用models.py檔案中dept對象，主要是在這一節中沒有使用相應的orm架構，是以就沒寫相應的model,這個在随後中會涉及到。
另外一個，我在擷取depts接口時，用的就不是jsonify方法了，而是内置的json.dumps轉換為json對象，我之是以這樣寫，是因為jsonify如果要傳回數組對象的話，必須要相應的對象實作一個方法傳回json資料，或者将這個對象轉成字典類型，然後循環周遊這個對象，比較麻煩，是以這裡我就直接使用json.dumps來進行轉換了。
在相應的路由注解上，我使用的就是dept.route，是以在定義了為dept的blueprint對象後，這裡的作用相當于當初定義的app Flask對象，但其實是進行了view層的路由後，最終還是注冊到了app上面，在代碼層面上實作了不同子產品之間的隔離。
3.2、user子產品
user子產品功能和代碼大部分和dept相同，這裡僅僅隻貼出代碼，不再描述具體的功能。
3.3、run.py檔案
最終Blueprint對象在run檔案之中進行注冊，如下：
其他的我就沒有再講了，config.py和manager.py在這些簡單的應用中還無需用到，講到後面再來說這些的作用。
4、運作
啟動run檔案，進行運作，請求
結果：
第一個接口請求成功：
請求第二個接口：
接口同樣請求成功，在這裡dept子產品就不去請求，結果是類似的。
5、總結
Blueprint其實本身隻是對view上的接口進行了注冊，然後整體挂載在app上，Blueprint本身的目的就是組織多子產品的平行共存，避免直接在app上注冊view，其實更多的隻是友善開發和代碼的維護，因為最終所有的views上的接口都仍然是直接挂載在app上，其實對應整個應用來說，沒有什麼明顯的差別。
Flask 中的Blueprint不是一個可插撥的應用，因為它不是一個真正的應用，而是一套可以注冊 在應用中的操作，并且可以注冊多次。
同時在這裡，我們不能使用多個flask對象來管理和注冊，因為這樣會導緻每個flask對象都有一個自己的配置，不好管理。
使用Blueprint，應用會在Flask層中進行管理，共享配置，通過注冊按需改變應用 對象。Blueprint的缺點是一旦應用被建立後，隻有銷毀整個應用對象才能登出lueprint。
綜合以上，簡單來說，Blueprint就是通過url找到view的一套機制，并沒有太過于複雜的邏輯。
原文釋出時間為：2017-03-30
本文作者：夏軒