背景原因

目前由雙牛掌柜為主導(dǎo)框架開發(fā)的一系列產(chǎn)品中，網(wǎng)絡(luò)請(qǐng)求框架請(qǐng)求到的數(shù)據(jù)是默認(rèn)解析成Model類的。即項(xiàng)目中不會(huì)手動(dòng)去解析網(wǎng)絡(luò)請(qǐng)求到的json數(shù)據(jù)。在項(xiàng)目中，使用封裝好的框架自動(dòng)解析成Model類。而且Model類使用JsonFormat工具生成，所以在項(xiàng)目的開發(fā)中，不會(huì)或者說是減少了由于手誤而打錯(cuò)了字段問題。

項(xiàng)目對(duì)網(wǎng)絡(luò)處理的繁瑣過程進(jìn)行了高度封裝。但是封裝的框架是基于后臺(tái)數(shù)據(jù)格式不會(huì)改變的情況，一旦后天返回的數(shù)據(jù)產(chǎn)生了變化，網(wǎng)絡(luò)解析就會(huì)發(fā)生錯(cuò)誤。

問題產(chǎn)生位置

所有設(shè)計(jì)到微信和支付寶兩種支付方式共存的地方。

分析

當(dāng)請(qǐng)求接口時(shí)支付寶返回的json如下（隱私數(shù)據(jù)已隱藏）：

{
  "status": 1,
  "msg": "支付寶支付所需數(shù)據(jù)",
  "result": "**************此處時(shí)吊起支付寶的數(shù)據(jù)，不做展示****************"
}

微信返回的json數(shù)據(jù)如下（隱私數(shù)據(jù)已隱藏）：

{
  "status": 1,
  "msg": "微信支付所需數(shù)據(jù)",
  "result": {
    "appid": "************",
    "partnerid": "************",
    "prepayid": "************",
    "package": "Sign=WXPay",
    "noncestr": "************",
    "timestamp": 1532915535,
    "sign": "************"
  }
}

調(diào)起微信或支付寶的數(shù)據(jù)位于result字段的數(shù)據(jù)中。根據(jù)上面兩種不同的格式，清楚的發(fā)現(xiàn)這是兩種不同的格式，一個(gè)是字符串，一個(gè)是鍵值對(duì)對(duì)象。這種情況在雙牛掌柜網(wǎng)絡(luò)請(qǐng)求框架中目前是不存在解析方式的。所以要給出一種簡便可復(fù)用的解決方案。

解決方案

雙牛掌柜框架中，支付流程過程高度封裝，對(duì)于不同的項(xiàng)目只需修改微信的appid。即使涉及到邏輯變動(dòng)，支付流程變動(dòng)也不會(huì)很大，或者壓根不會(huì)變動(dòng)。

1.雙牛掌柜支付流程如下（余額支付沒舉例，但是已封裝）

雙牛掌柜支付過程.png

在項(xiàng)目實(shí)際使用的過程中，只需復(fù)寫網(wǎng)絡(luò)請(qǐng)求獲取信息，和回調(diào)支付這兩個(gè)地方，因?yàn)椴煌闹Ц段恢脮?huì)使用不同的支付接口，接口會(huì)變。其他的地方不會(huì)發(fā)生變化。

解決方案一

接口返回不同數(shù)據(jù)這個(gè)問題很早就出現(xiàn)了，當(dāng)時(shí)由于項(xiàng)目緊張，采取了一個(gè)接口根據(jù)返回?cái)?shù)據(jù)的不同，分成了兩個(gè)接口；在進(jìn)行邏輯處理的時(shí)候，手動(dòng)判斷調(diào)用對(duì)應(yīng)的接口。但是這種實(shí)現(xiàn)的方式過于繁瑣，所有的邏輯過程都要考慮清楚，代碼編寫的過程中不停的造輪子。

寫兩套接口，意味著如流程圖所示的流程會(huì)走兩遍，加大了代碼的復(fù)雜度。

此處不做代碼展示。

解決方案二

第二種方式的核心思想是代碼解耦合。由于之前網(wǎng)絡(luò)請(qǐng)求框架高度封裝，所以整體上是高內(nèi)聚低耦合，但是如果想對(duì)網(wǎng)絡(luò)請(qǐng)求框架進(jìn)行自定義，又必須姐耦合，這就是編程中的矛盾點(diǎn)。

1.手動(dòng)解析json數(shù)據(jù)，讓框架不在解析。

此處操作乍一看挺復(fù)雜，但是實(shí)際操作的過程中并不是很復(fù)雜。將接口返回?cái)?shù)據(jù)的泛型替換成ResponseBody就可以獲取到未解析的數(shù)據(jù)了。代碼如下：

 /**
   * 我要買單
   *
   * @param payCode
   * @param zflx  1掃碼買單 2附近商家我要買單 3商家報(bào)單 4充值 5升級(jí) 6商城消費(fèi)
   */
  @FormUrlEncoded
  @POST("Near/wymd")
  Observable<ResponseBody> wymd(
      @Field("snzg_user_id") String userId,
      @Field("shop_user_id") String shopUserId,
      @Field("money") String money,
      @Field("bd_id") String bdId,
      @Field("pay_code") int payCode,
      @Field("zflx") int zflx
  );

當(dāng)請(qǐng)求到數(shù)據(jù)時(shí)，把數(shù)據(jù)轉(zhuǎn)成String格式，就可以對(duì)數(shù)據(jù)記性拆箱操作了。代碼如下：

 @Override
 public void handleSuccess(Object result) {
    toPay(result.toString(), wymd.getPaycode());
 }

然后再使用Gson解析工具，將json轉(zhuǎn)換成對(duì)象。

  protected void toPay(String payInfo, int payCode) {
    
    //余額
    if (payCode == 3) {
      payEnd("支付成功");
    }
    
    //微信
    if (payCode == 2) {
      wxPayResult = GsonUtil.parseJsonWithGson(payInfo, WxPayResult.class);
      weChatPay();
    }
    
    //支付寶
    if (payCode == 1) {
      alipay(payInfo);
    }

  }

至此問題已解決。

總結(jié)

代碼高度封裝帶來編程的便利，但是對(duì)于一些變數(shù)也會(huì)產(chǎn)生一些難以解決的問題。這就需要在代碼編寫之前就要對(duì)整理進(jìn)行一個(gè)分析，分析一定要全面，而且代碼一定要可擴(kuò)展，不能寫死，不能讓某種變數(shù)導(dǎo)致框架不能使用。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論