#PhalGo-ADM思想數據庫
關於ADM思想主要是指在API開發中使用API,Domain和Model三層結構,PhalGo從PhalApi中學習而且推崇這種設計模式,這種模式的好處在於分工明確,業務複用,數據複用能夠減小複雜業務重複的代碼量,**不少框架關心性能,而不關心人文;不少項目關心技術,而不關注業務。**ADM設計就是從業務的角度出發創建的開發規範.設計模式
##ADM分工協做緩存
###Api框架
Api層能夠理解爲是請求開始結束以及組合業務的地方,主要負責如下幾件事情:函數
咱們能夠看一個獲取用戶詳情接口的例子:性能
func (this *User_Api)GetUserInfo() echo.HandlerFunc { return func(c echo.Context) error { Request := phalgo.Requser{Context:c} Response := phalgo.Response{Context:c} defer Request.ErrorLogRecover() //獲取請求參數 id := Request.GetParam("id").GetInt() //拼接領域層業務 user, err := this.Domain.User.GetUserInfo(id) if err != nil { return Response.RetError(err, 400) } //返回結果 return Response.RetSuccess(user) } }
(1)Api接口層應該作:學習
(2)Api接口層不該該作:this
###Domain設計
Domain能夠稱之爲領域層,是ADM(Api-Domain-Model)分層中的橋樑,主要負責處理業務規則。Domain層存在的目錄是爲了把複雜業務拆分紅一個一個小模塊而後組織起來實現複雜的業務,從而達到代碼複用,拆分複雜業務的做用.日誌
####舉個栗子
**場景:**咱們在傳統MVC開發的時候,使用控制器來處理業務,咱們可能會寫不少的重複代碼來驗證用戶提交的信息是否ok,好比完善信息的時候驗證郵箱,在修改用戶信息的時候也要驗證修改的郵箱,在管理的時候去編輯一個用戶的時候也可能在去驗證郵箱,這個時候咱們的驗證邏輯代碼已經重複寫在了3個地方,若是有一個需求加入了電話號碼,那麼你須要在3個地方加上對電話號碼的驗證邏輯
場景一併不難以遇到,並且在複雜的業務狀況下重複使用的業務邏輯會更多,若是咱們使用了Domain來處理用戶修改前的驗證那麼咱們只須要修改這個驗證邏輯加上對電話號碼的驗證,那麼全部須要驗證用戶信息的地方就會所有生效,而不用去作重複的工做而且避免遺漏的風險
下面是咱們獲取User詳情的Domain層的實現,它不單單只是能夠用在獲取用戶詳情也能夠用來驗證用戶ID是否有效,增長代碼複用性減小修改代價
func (this *Domain_User)GetUserInfo(id int)(Model.User,error) { user, err := this.Model.User.GetInfoById(id) if err != nil { return user, errors.New("UserInfo There is no") } return user,nil }
一個函數若是超過了一屏那將會影響到閱讀者的理解,使用領域層拆分笨重的業務能夠很好的解決這個問題
###Model
Model層想必不用說了,就是和數據庫通信獲取數據,Model層是單純的不帶任何業務只是簡單的獲取數據庫數據,咱們看一段Model層代碼:
type User struct { Id int `gorm:"column:aId"` Name string `gorm:"column:name"` Passwd string `gorm:"column:passwd"` Email string `gorm:"column:email"` } func (User) TableName() string { return "user" } func (this *User)GetInfoById(id int) (User, error) { User := User{} err := phalgo.GetORM().Where("id = ?", id).First(&User).Error return User, err }
注意:Model層只應該獲取數據而後結束關於沒有獲取到數據,獲取出錯等狀況拋出到Domain層進行處理,這樣能夠增長靈活性,好比經過用戶名是否重複和經過用戶名稱獲取ID,一個返回存在纔算異常,一個返回不存在纔算異常,具體更具業務不一樣體現也不一樣,因此Model層處理並不合適
##層級調用的順序
總體上講根據從Api接口層、Domain領域層再到Model數據源層的順序進行開發。
在開發過程當中,須要注意不能越層調用也不能逆向調用,即不能Api調用Model。而應該是上層調用下層,或者同層級調用,也就是說,咱們應該:
爲了更明確調用的關係,如下調用是 錯誤 的:
這樣的約定,便於咱們造成統一的開發規範,下降學習維護成本。
好比須要添加緩存,咱們知道應該定位到Model層數據源進行擴展;若發現業務規則處理不當,則應該進入Domain層探其究竟;若是須要對接口的參數進行調整,即便是新手也知道應該找到對應的Api文件進行改動。