原因
Python在AI,AR VR這塊使用愈來愈普遍。同時在Web方面也有不少成熟的框架。而我自己因爲使用Flask 比較多,我的認爲就是比較簡單,容易入手,可定製化強。這裏我將我通過多個項目屢次迭代的。自認爲還能夠的框架結構整理出來。方便本身能夠更容易建立新項目。
你們也知道我錄製了兩門關於python的課程都是基於這個定製化的分層結構的框架開發系統的
目錄結構
.
├── api api存放
│ ├── controllers 全部的C層放在這裏
│ ├── interceptors 攔截器相關
├── application.py 封裝的Flask的全局變量,包括app,數據庫等
├── common 存放公用部分
│ ├── libs 公用方法或者類
│ ├── models 全部的數據庫model
├── config 配置文件
│ ├── base_setting.py 基礎配置
│ ├── develop_setting.py 開發環境
│ ├── local_setting_demo.py 本地開發環境配置demo
│ └── production_setting.py 生產環境的配置
├── docs 文檔存放
│ ├── Mysql.md 全部數據庫變動必須在這裏記錄
├── jobs 定時任務
│ ├── bin
│ └── tasks 全部定時任務都存放在這裏
├── router 路由配置入口
│ ├── www.py 對應web的路由配置
│ └── api.py 對應api的路由配置
├── manage_web.py web啓動入口
├── manage_job.py job定時器啓動入口
├── manage_api.py api啓動入口 (若是有api的話)
├── requirements.txt python 擴展
├── uwsgi.ini 生產環境uwsgi
├── web HTTP存放
│ ├── controllers 全部的C層放在這裏
│ ├── interceptors 攔截器相關
│ ├── static 靜態文件
│ └── templates 模板文件
功能特性
目錄結構分層
相信代碼分層不少人都據說。可是未必都能理解這樣作會有什麼好處。對於小型項目可能分不分不會有什麼太大的問題,可是若是對於一個大型項目,分層就會帶來特別明顯的好處。你們翻閱代碼知道去什麼地方找,讓開發和維護更加簡潔。
多環境配置隔離
flask默認官方是有環境配置隔離方法的,我我的以爲官方的方式不太好,因此就結合之前使用php和在實際開發和運維當作本身規定了一套方案。以下 經過不一樣的配置文件作到多環境覆蓋。
例如 develop 能夠是開發環境,production 是 生產環境,還能夠增長test 爲測試環境。經過環境變量ops_config 來進行切換
├── config 配置文件
│ ├── base_setting.py 基礎配置
│ ├── develop_setting.py 開發環境
│ ├── local_setting_demo.py 本地開發環境配置demo
│ └── production_setting.py 生產環境的配置
支持多APP模式
不少狀況咱們可能要開發好幾個應用,只有一個知足不了咱們的需求。例如增長一個api,增長一個admin 都有可能。爲了知足這種狀況我就作了定製化架構。經過不一樣的入口來決定不一樣的應用
├── api api存放
│ ├── controllers 全部的C層放在這裏
│ ├── interceptors 攔截器相關
├── router 路由配置入口
│ ├── www.py 對應web的路由配置
│ └── api.py 對應api的路由配置
├── manage_web.py web啓動入口
├── manage_api.py api啓動入口 (若是有api的話)
├── web HTTP存放
│ ├── controllers 全部的C層放在這裏
│ ├── interceptors 攔截器相關
│ ├── static 靜態文件
│ └── templates 模板文件
支持定時器
爲了方便咱們寫定時器,我本身寫了一個簡單的腳手架。方便使用。網上也有不少其餘的定時器插件。可是從我時間實踐得來,定時器當成一個獨立的應用會更好,不要和其餘應用有任何耦合最好。
├── jobs 定時任務
│ ├── bin
│ └── tasks 全部定時任務都存放在這裏
├── manage_job.py job定時器啓動入口
快速使用
相關截圖