如何深刻理解PhalApi框架三層結構Api+Domain+Model模式

1. Api+Domain+Model

其實這樣的三層結構和java中的web+service+dao比較像，和咱們日常所說的MVC開發模式也是很是想象。只是說web和api一個進行頁面顯示一個不進行頁面顯示這個區別，本博文主要着重講一下這三層在Phalapi中分工是怎麼樣的，他們分別擔當者什麼樣的角色,須要作什麼樣的事情。

1.1 Api層

爲何說Api層像java中的web層呢，由於他們有一個共同的特性就是接受請求和返回結果。只不過java中沒有表現得那麼強烈，它會經過控制器把請求轉發到service層做處理，並將處理結果在頁面展現，因此Api更像擔當控制器(C)的做用。

Api層中須要作的事情以下：

a. 註冊接口/定義接口和控制請求參數

這是首先要作的事情,和在web中的url同樣,就是添加須要接受的參數以及對參數進行驗證，以下：

 

public function getRules(){
    return array(
        'goodsCategoryList' => array(
            'parent_id' => array('name' => 'parent_id','type'=>'int', 'default' => '0','desc'=>'父類id'),
        ),
        'goodsSecAndThirdCategoryList' => array(
            'parent_id' => array('name' => 'parent_id','type'=>'int', 'require' => true,'desc'=>'父類id'),
        ),
    );
}

b. 進行業務、邏輯的拼接

在這裏進行業務、邏輯拼接，好比說是查詢商品分類列表(依查詢商品爲例)接口須要作兩件事情，第一查詢出商品的分類列表信息，第二查詢把查詢出的信息進行 返回，應該是以下樣式:

/**
  * 獲取商品分類列表
  * @desc 用於獲取商品分類列表
  * @return int ret 返回接口狀態碼，其中：200成功，400非法請求，500服務器錯誤
  * @return int code 返回請求狀態碼，其中：1正常，0不正常
  * @return array data 返回數據信息
  * @return int id 商品分類id
  * @return string name 商品分類名稱
  * @return string mobile_name 手機端顯示商品分類名
  * @return int parent_id 父類id
  * @return srting parent_id_path 家族圖譜
  * @return int level 分類等級
  * @return int sort_order 順序顯示
  * @return int is_show 是否顯示，其中1顯示，0不顯示
  * @return string image 分類圖片路徑
  * @return int is_hot 是否推薦爲熱門分類，其中1爲推薦，0爲不推薦
  * @return int cat_group 分類分組默認0
  * @return int commission_rate 分傭比例
  * @return string msg 返回信息提示，成功：success，失敗：error
  * @demo http://localhost/Api/Public/tpshop/index.php?service=Goods.goodsCategoryList
  */
 public function goodsCategoryList(){
     $goods_domain = new Domain_Goods();
     $info = $goods_domain->goodsCategoryList($this->parent_id);
     return $info;
 }

1.2 Domain層

Domain層主要負責的是具體的業務實現,如數據獲取，一個Domain方法就是一個小的業務具體實現(注意儘可能把業務劃分得細一點方便通用)

public function goodsCategoryList($parent_id){
        $goods_model = new Model_Goods();
        $result = $goods_model->goodsCategoryList($parent_id);
        return $result;
    }

1.3 Model層

Model層其實無需多講，也就是把數據庫操做單獨提煉出來統一處理，以下：

public function goodsCategoryList($parent_id){
       $goods_model = DI()->notorm->goods_category;
       $goodsCategoryList = $goods_model->where("parent_id = $parent_id AND is_show=1")->order("parent_id_path,sort_order desc")->fetchRows();
       if(!empty($goodsCategoryList)){
           $info['code'] = 1;
           $info['data'] = $goodsCategoryList;
           $info['msg'] = 'success';
       }else {
           $info['code'] = 0;
           $info['msg'] = 'error';
       }
       return $info;
   }

2. 三層結合使用的好處

2.1 結構清晰，互不干擾

就我我的感受來講，在實際開發中使用這樣的三層結構帶來的最大的好處在於結構清晰，爲何這麼說呢？由於每一層須要作的事情都是很是獨立的，你永遠不會在A PI層中看到數據操做的代碼，因此在排查問題的時候，若是是數據出了問題，確定不會去API層裏面去找，這樣就很是方便錯誤的定位，再者就是代碼可讀性很是高，相對 於mvc框架來講這樣的好處是很是明顯的。

2.2 高度解耦，靈活高可用

帶來的第二個很重要的好處就是解耦和高可用，高可用體如今Api能夠重複利用Domain，Domain能夠重複利用Model，這樣能夠減小不少沒必要要的代碼量。若是相互 的關係僅僅只是拼接(除非是結果會互相影響)的狀況下就實現瞭解耦。

2.3 分工合做，提升效率

在有這樣的一套規範以後在分工合用時，對方不須要去看你的代碼具體實現了什麼，只須要看你這個方法幹了什麼，直接拿起來用就能夠了，固然是在業務劃分紅小塊 的狀況下，並且能夠很明確的劃分出來模塊，當你須要用到對方的模塊的時候只須要讓對方提供便可，這樣能夠增長模塊的專一性，從而提升合做開發的效率。

3. 總結

其實在剛剛接觸這個框架的時候，我也是特別不能理解這樣劃分的做用，在後面的開發和別人的交流中進行了一些嘗試後，發現這樣用起來確實有不少的好處，但願今天的博文能讓你們理解這樣的一種規範能夠帶來不少的好處，而且本身去嘗試和使用。