改方法返回array(); 在外部統一入口、出口處再返回 JSON出去。

sysapi_ecoupon_order

接口調用的kernel::single("sysapi_ecoupon_order")->create($params, $msg);這里面做實際的業務處理，錯誤信息是通過 $msg 向上傳遞出去，外部沒辦法通過 $msg 獲知對應的 code。然后給前端童鞋講這種情況沒辦法返回 code給你。

前端就只能通過判斷 msg的方式來修復該問題
然后寫了如下 demo：

然后提交，測試，通過，上線，N天后

有人跑過來講：下單頁 與 個人中心的提示有點不同，貌似多了個 "!"。（舉例而已，更多的可能是提示不友好、錯別字等情況）

然后后端同學修改為 $msg = app::get("ecoupon")->_("用戶未登錄，請登錄"); 提交，測試不通過，前端同學再修改為if("用戶未登錄，請登錄" == data.msg)，提交，測試通過

// 如此反反復復

終究有一天：產品、測試，前端、后端混戰了一場。N人，卒.....

最終前后端得出結論：要想對用戶實現更加友好的體驗，前后端數據必須有個標識具有唯一性，不變性。而現在用的 msg卻不具備，還是得用 code。并且這里前后端極度耦合msg。

后端童鞋回來繼續修改代碼，開始著手給這里添加上相應的 code。
開始思考該怎么添加 code，現在的問題是 create( ) 方法可能是其他童鞋開發，內部返回的提示信息，我這邊是調用者，不能確定方法內部到底會返回什么提示信息，無解。

忽然，有一天想到，我在調用該方法之前檢查下用戶有沒有登錄就OK了，然后開始寫如下實現：

public function create($params)
{
    $member = app::get("b2c")->model("members")->get_current_member();

    // 登錄驗證
    if (empty($member)) {
        return array("code" => "00008");
    }

    $msg = "";

    $order = kernel::single("sysapi_ecoupon_order")->create($params, $msg);
    if (!$order) {
        return array("code" => "", "data" => array(), "msg" => $msg);
    }
    return array("code" => "00000", "data" => $order);
}

呵呵，好機智的少年。
然后告訴前端，這里可以返回 code了，前端愉快的刪掉原來那坨判斷 msg的代碼，而在 ajax請求的地方統一判斷 code就能預知用戶未登錄，做出相應的操作。

經測試，上線。一切又回到了美好時光。

隨著時光的流逝，業務的增加，后端童靴發現Order類里面如下 demo：

這都是什么玩意............ 然后開始封裝，稍微好了點

又過了一段時間，有人過來說創建訂單還需要優化體驗，
點擊創建訂單提示如下：

超過最大購買量——給出提示，繼續留在創建訂單頁

該商品已賣光或已下架——引導用戶去商品列表頁

這時，前端童鞋告訴后端童鞋，商品下架的時候，你也應該返回一個狀態碼。

后端童鞋開始打算添加 code，發現如下 demo

這里的提示信息是 $msg 返回的，用戶登錄外部可以提前檢測，這里的商品能否購買要實現添加 code也需要提前檢測，將來要是需要添加類是功能豈不是...... 每需要一個精確的 code返回出去，這里就需要添加檢測，這里代碼將會變得無法直視。
況且這里本該在業務里面檢測，一切不那么友好起來了。

再次思考，代碼寫的不爽了，一定是哪里不對

開始懷疑 public function create($params, & $msg) { } 這里不應該是通過 & $msg 來作為 調用者與 被調用者之間的 錯誤信息通信約定，一切的問題都出在了這里。錯誤消息向上傳播的約定不合適

如果這里約定的是 code作為錯誤向上傳播一切的問題即將不復存在。在調用業務方法之前的檢測代碼就都可以去掉了，代碼簡約，一切又美好起來。

接下來繼續思考，使用 code作為業務處理失敗消息傳遞問題又來了

現在已有的業務代碼都是如此定義public function create($params, & $msg)，怎樣更加友好的替換成 code

如果使用 code，code只能服務器端 與 前端約定的一個具有唯一性的標識(code 比 msg 對國際化的實現更加容易)但是并不能直接展示給用戶，那么就需要定義每個 code 的代表的意義 與 對應的提示信息。那么問題來了，code 應該已怎樣規范來定義所代表的含義

再來看如下常用的兩種方法定義：

public function create($params, & $msg)

public function create($goodsId, $num, & $msg)

第一種方式，參數通過一個 $params數組傳遞過來，方法內部在把錯誤提示放到 $msg中。

好處：$params是個數組，里面參數可以任意添加

缺點：該方法調用者在外部不能知道該方法需要什么參數，必須來看該方法內部實現，做出對應的數組 key的轉換(如： user_id 轉 userId)。方法調用者 與 方法實現 極度耦合。維護成本大、出Bug系數高

第二種方式，按基本類型分別傳遞單個參數

好處：方法調用者根據方法定義就能夠知道方法具體需要的參數，調用方法時不需要作 key轉換，只需要傳遞對應的參數即可

缺點：參數數目過多時，慘不忍睹

這里有如下問題：

這里如何已一種更加容易維護，擴展的方式來處理（Java里面方法參數已對象的方式傳遞可以借鑒）

這里的& $msg 真的合適嗎，如果是第二種方式定義的方法，以后擴展個 $phone 該如何處理？public function create($goodsId, $num, & $msg, $phone="")這樣么？怎么看怎么蛋疼

再來看不通過 & $msg傳遞錯誤信息之后的代碼

看似實現了，但是方法調用者，怎么調用怎么蛋疼，一會返回狀態碼，一會返回訂單信息，完全兩種類型。

得出以下結論：

業務處理失敗消息要以 code 的方式向上傳遞給調用者

業務處理失敗消息以參數的方式傳遞不是很適合，并且不能以 return的方式返回

再次思考，最終從 Java里面想到了一點思路（幸好是 Java出身。疑問：為何面試的時候 Java的工作經驗都不算在 PHP工作經驗里呢，并沒有因此而加分）

自定義一個異常類，包括 codo屬性 和 msg 屬性

凡是遇到業務不能正常處理的時候就創建一個異常對象，設置對應的 code 或者 msg屬性(為了減少 code泛濫，這里的 code 與 msg 可以2選一，如果前端需要做精準的處理，就設置 code，如果只是為了給用戶提示，就只返回 msg，則可以減少一個 code)，然后拋出異常

方法調用者在外部統一捕捉該異常，如 接口的統一入口出口的方法內部處理

  
因個人工作時間、項目經歷不多、歸根結底經驗不足。現在將該方案寫下來，還望有經驗的大神拍磚，以免給團隊挖坑，以上 $msg 就是 N久以前埋下的坑。

該文章發布在自己站點地址：http://www.webdevs.cn/article/91.html