背景原因

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

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

問題產(chǎn)生位置

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

分析

當(dā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)這是兩種不同的格式，一個是字符串，一個是鍵值對對象。這種情況在雙牛掌柜網(wǎng)絡(luò)請求框架中目前是不存在解析方式的。所以要給出一種簡便可復(fù)用的解決方案。

解決方案

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

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

雙牛掌柜支付過程.png

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

解決方案一

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

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

此處不做代碼展示。

解決方案二

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

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

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

 /**
   * 我要買單
   *
   * @param payCode
   * @param zflx  1掃碼買單 2附近商家我要買單 3商家報(bào)單 4充值 5升級 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)請求到數(shù)據(jù)時(shí)，把數(shù)據(jù)轉(zhuǎn)成String格式，就可以對數(shù)據(jù)記性拆箱操作了。代碼如下：

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

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

  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é)

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

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

最新評論