1. 程式人生 > >使用DRF和flask寫註冊檢視差異總結

使用DRF和flask寫註冊檢視差異總結

不接受反駁 本人很菜。寫總結只是為了增加經驗! 

先說說個人flask和django框架的使用感受

用flask第三方擴充套件自己找包

django則不同了。django真的太大了。。 

你如果真的用django去開發一箇中小型專案那你感覺真的是殺雞用牛刀

不過我個人認為用flask寫起來舒服很多 因為django你要考慮的因素太多太多了。比如python2只認識mysqldb 但python3 卻使用 pymysql 你還需要給資料庫改名 等等

有人說flask只適合開發中小型專案。。。 個人感覺不是。 我之前從網上搜過很多flask和django框架的區別。差異和喜歡程度,

為啥公司喜歡用django的多一點,因為django開發效率高啊。你flask瘋狂找擴充套件時候。django估計都開始寫了吧 再說效益都是錢啊!!!

再說django自帶的站點也不錯。 因為有人給他的站點做了二次開發啊

而flask則是。。大牛都喜歡用。我聽他們說 flask開發真的很爽,(我還在瘋狂的找擴充套件包)雖然不如django齊全但是flask開發程度大小是需求說了算的

可以很大也可以很小而且省去了很多砍框架的事情,用什麼我裝什麼擴充套件包就是了。擴充套件包也一直在更新,很舒服

django則不同,目錄不需要自己搭建 直接一個 django-admin startproject    子應用 python manage.py startapp 完事

說說18年新火的 django rest framework吧

這東西太強大了。 他不是框架 他是基於django實現的一個擴充套件包

封裝程度極高 

說實話第一次用這都寫完註冊頁面了,我還是有點記不清 那幾個APIViews 和VIEset

只知道寫的時候看看 那個最合適那個最方便!!就繼承那個class

這DRF重點就是理解 序列化和反序列化 我個人感覺理解了就算是入門了。

序列化 == 模型類> python字典>json

反序列化 == 前端傳送資料 >經過serializer > python字典> 模型類 

通俗說吧。 序列化 就是你寫好的模型類 然後轉成 字典然後json

反序列化就是接收前段資料經過校驗 然後轉成python的字典 你取的時候跟字典一樣

而且返回也不是httpresponse了 是drf自帶的response

Serializer(instance=None, data=empty, **kwarg)

說說模組部分吧 
分為兩個部分一個分為校驗一個是使用者模組
這不正符合 mvt 設計模式嘛!
使用資料庫mysql nosql使用redis
第一個API寫的是返回圖片驗證碼 使用的是最原生的APIView 
APIView和View不同之處
APIView繼承 django 原生view
傳入檢視的request 不是django原生的HTTPrequest
而且任何APIExcotion都會被捕捉
如果你說mysql和redis異常怎麼辦, 自己寫!!
而且dispatch()之前 會自動校驗身份 流量控制
檢視返回方法是 response 檢視會為響應資料設定render符合前端要求協議
前端發來請求並在路徑上生成uuid
呼叫第三方庫 生成驗證碼
將image加上uuid 拼接為鍵 圖片驗證碼為值存入redis資料庫
返回圖片用的django原生的Httpresponse 記得設定型別  conttype=image/jpg
#第二步寫傳送簡訊驗證碼
使用GenericAPIView  
Genercapiview 繼承apiview 
主要提供了序列化器和資料庫查詢方法
最大特點是!!這哥們 可以配合五個類一起使用!!那五個類自己看文件吧。。
第一步指定序列化器!
序列化器裡面是啥等會說
第二步定義get屬性接收手機號
指定序列化器 
驗證序列化器 如果有異常拋異常
生成圖片驗證碼
呼叫celery傳送簡訊(celery做成一個獨立檔案。獨立啟動分離出來就能用那種。這麼做解耦高。有益於日後拓展 而且他報錯!!一般報錯在你指定的redis資料庫內!!)
使用 redis管儲存兩個 一個以sms_+手機號為鍵 值為驗證碼 儲存 一個以sms_flak手機號為鍵 值你隨便 判斷是否是60秒內頻繁傳送簡訊
而且使用管道切記一定得提交!!!

說說驗證器都發生了什麼吧
首先校驗 uuid 是否是uuid 型別
然後校驗前端傳來的簡訊碼是否是你儲存的位數
定義校驗的欄位:欄位的名字要麼和模型類屬性名相同,要麼和傳入的校驗引數胡名字相同(千萬別皮)
然後聯合校驗簡訊驗證碼需要用到uuid 所以uuid也傳過來。 因為儲存時候是用到了uuid
取出redis儲存的真是驗證碼 
哦對了。由於drf他不捕獲資料庫異常所以自定義異常除了mysql 連redis也寫了
所以要踹一腳
取出之後第一件事就是把儲存在redis資料庫的真實簡訊驗證碼給刪了!!
防止暴力撞庫
需要注意的一點就是 py3裡面redis取出來的需要encode一下
然後為了我們偉大的使用者體驗好一點
還是給轉成小寫在比較吧。
然後從 self.context['view'].kwargs['moble']取出手機號
去redis資料庫查一下
如果有就給他一個傳送簡訊頻繁
因為如果你是第一次註冊redis資料庫裡肯定沒有sms_flask手機號
因為你第一次來發送簡訊肯定flask+sms是空的
發簡訊總體流程是!
首先接收請求~!然後 調到serializer裡去校驗各個引數
然後 執行檢視函式 返回 傳送簡訊ok~

註冊檢視
使用的是createAPIVIEW
啥都不用做
就指定序列化器就完事
為啥? 有時間的話開啟createapiview一看原始碼就知道了。
重點就在序列化驗證器裡面
序列化驗證器使用的是
serializer.ModelSerializer
他和serializer.serializer的區別是
他提供自動校驗模型類引數
自動為Serializer生成validators,比如unique_together
但是!你需要指定而外欄位
為啥?
你資料庫欄位裡有 同意 和passwordtwo 簡訊驗證碼等等嘛
這裡你需要注意的
那些欄位你是用來輸入的(write_only)
那些欄位你是用來輸出的(read_only)
你輸入的password是write_only把
不能輸出吧
你手機號 使用者名稱是read_only把
而且你需要追加校驗額外欄位
我記得沒錯的話
他自己提供的校驗使用者名稱沒有min_length
max_length是150位元組
瘋了吧!
校驗密碼長度(你自己咋定義規則怎麼校驗)
正則手機號等等
然後重寫了 create方法 
因為用jwt做了狀態保持


登入函式等我有時間了在寫