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

sysapi_ecoupon_order

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

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

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

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

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

// 如此反反復復

終究有一天：產(chǎn)品、測試，前端、后端混戰(zhàn)了一場。N人，卒.....

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

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

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

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請求的地方統(tǒng)一判斷 code就能預知用戶未登錄，做出相應的操作。

經(jīng)測試，上線。一切又回到了美好時光。

隨著時光的流逝，業(yè)務的增加，后端童靴發(fā)現(xiàn)Order類里面如下 demo：

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

又過了一段時間，有人過來說創(chuàng)建訂單還需要優(yōu)化體驗，
點擊創(chuàng)建訂單提示如下：

超過最大購買量——給出提示，繼續(xù)留在創(chuàng)建訂單頁

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

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

后端童鞋開始打算添加 code，發(fā)現(xiàn)如下 demo

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

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

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

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

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

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

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

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

public function create($params, & $msg)

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

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

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

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

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

好處：方法調(diào)用者根據(jù)方法定義就能夠知道方法具體需要的參數(shù)，調(diào)用方法時不需要作 key轉(zhuǎn)換，只需要傳遞對應的參數(shù)即可

缺點：參數(shù)數(shù)目過多時，慘不忍睹

這里有如下問題：

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

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

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

看似實現(xiàn)了，但是方法調(diào)用者，怎么調(diào)用怎么蛋疼，一會返回狀態(tài)碼，一會返回訂單信息，完全兩種類型。

得出以下結論：

業(yè)務處理失敗消息要以 code 的方式向上傳遞給調(diào)用者

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

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

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

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

方法調(diào)用者在外部統(tǒng)一捕捉該異常，如 接口的統(tǒng)一入口出口的方法內(nèi)部處理

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

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