Django 使用體驗

用過許多的web開發框架，我是隨着 Python這股熱潮來參考的 web 開發方法 Django，以前也有使用過 Java 的 springMVC，RoR 框架。就着開發比較常見的幾個問題，談談本身粗淺的見解。

結構：語言體系和開發習慣，Java 相對的定義均可以本身盡心約束和配置，徹底能夠按照本身公司的結構和習慣來編寫，因此不存在什麼靈活性一說。符合本身公司和團隊的規範就好。Django也相對相似，對靜態目錄經過系統自帶的os，path和setting配置能夠指定相應的目錄做爲靜態目錄或文件的上傳目錄等相似的功能。在系統的功能規劃方面，經過Django生成的工做目錄會提供基礎的程序，包括初始的wsgi，setting，url等項目基礎文件以外，經過django manager startapp會在同級目錄下生成相對應的app目錄結構，總體來說文件結構也廣泛固定。RoR則依賴「約定大於配置「的信條把絕大部分的目錄都規定的妥穩當當。作過相似開發的開發人員基本上都熟悉。完整的mvc目錄結構，標準的public，static等都是按照通用的工程結構而來。

至於開發語言，單單討論Java，Python，Ruby孰優孰劣徹底沒意義，不討論，但Python那種強迫症的tab間隔習慣我很喜歡。

經常使用的開發場景

• 自動化工具方面，隨着Docker，Jenkins之類的工具推出。Java的自動部署和腳手架能夠徹底本身實現，可是就純框架自帶的功能而言，Django，RoR自帶的腳手架確實比較優秀，Django能夠經過腳手架自建工程、創建模塊、經過模型建立數據庫、創建數據庫遷移任務。而RoR在這類功能基礎之上還提供了一鍵遠程部署、數據庫版本回滾、
• 開發流程和模板：RoR,Django均可以經過指令來生成模塊代碼，Java沒有。Django開發中也封裝了一些經常使用的ListView，DetailView，TemplateView來減小開發的代碼量。生成完模塊代碼後，Django能夠經過系統自帶的Model層的定義在app中的admin.py經過@註冊進入系統自帶的後臺管理中。不須要任何開發就能夠實現web界面對數據的管理功能。這一點我相信是Django最強大也是最遭詬病的地方。優勢在於不須要任何代碼開發就能夠把模型一件注入進入管理平臺。只須要配置模型的字段就可實現模型的CURD，List頁面的過濾查找。缺點是管理平臺很是死板修改難度極大，好比要修改後臺的模板風格、對模板變量添加一些經常使用的處理（好比把{{ temp }}從1替換成爲」男」都須要編寫代碼來實現。）模板中不能使用Python的功能，須要符合模板的Api語法。Java，RoR則能夠徹底使用語言自帶的功能，而且Java能夠選擇各種模板庫做爲本身的view展現層，可是他們都沒有Django自帶的實現須要自行開發。
• 相關的插件之類：在這裏的表現其實都挺不錯的，相對來講可能Django，RoR更加的讓開發人員「不用太想事兒「經過簡單的配置就能夠完成相關的功能，例如：分頁、查詢後參數保持的分頁，防CSRF提交、CKEditor富文本編輯框、文件上傳、圖片切圖等。相對而言，Django，RoR由於其插件方式，而且自帶了相關的初始插件腳本。如：CKEditor經過pip install，bundle install以後，能夠運行一個執行腳本，默認把相關的上傳路徑，上傳的文件類型，圖片的自動切圖等相關配置經過腳本自動生成，更加省力而已。而Java的強項都是在系統架構方面，如：工做流模塊、系統權限模塊、數據緩存、分片、微服務等架構層級。因此就平常的業務代碼開發而言Django，RoR的親和力更好，開發中下規模的系統而言。Django，RoR更加具有優點。
• API和測試：基本都差很少，swagger應該都會有相關的支持，至於測試我想Java應該更加優秀。自己就是一個龐大、繁雜的體系，定製化的自由度也更高。至於文件結構之類，那就是蘿蔔白菜的事也沒有討論的必要。

我的的感受，其實Django的開發很尷尬，介於中間的位置。說全自動又沒有Rails好，說定製程度和靈活性也沒有Java好，我不太喜歡它的繼承父類而後重寫的方式。一開始都爲了這個開發繞了很久，報錯信息感受也沒有特別出彩。若是是純選擇開發web我應該仍是會選擇RoR。接下來就是我的的看法了，由於Python對於大數據、網絡抓包、系統底層的服務編程更好。這也是相對RoR的優點。至於Java，嗨，世界第一還有什麼好說的。以上是我做爲一個徹底沒有接觸過 Python 的萌新的使用體驗。

推薦閱讀：胡陽編寫的 《Django企業開發實戰高效Python Web框架指南》，完完整整的本身走一遍，相信每一個人都會有本身的開發理解。