LitePal + Gson + Volley的ORM框架嘗試方案

為了緊跟技術潮流，目前的項目開始采用ORM的思想進行重新設計。

數據庫采用輕量級ORM框架LitePal，Json解析采用Gson，網絡框架采用Volley。

如果只是單純的將這些第三方框架引進來，事情就簡單多了，但這樣意義不大，所以我們就結合項目的需求探索這三者的結合方案。

Volley的改造比較大，結合了OkHttp，在API方面采取了鏈式調用的方式，可以像這樣寫代碼：

Volley.url("").params("", "").done().fail()

Gson主要是和LitePal進行結合。

這里有個問題：業務對象和表對象一般都是不對應，所以Gson轉換來的對象不能直接存進表里面，中間要有個轉換。

當然，簡單的方法就是聲明一個業務對象，Gson直接轉換為業務對象，然后再存進表對象。但這樣的話，業務對象里一定有很大的代碼量都是用來存取數據，因為只能通過getter和setter來執行。

於是Gson就轉換為表對象，然后在業務對象中綁定表對象，由表對象執行數據庫相關操作：

User user = gson.fromJson(json, User.class);
UserEntity entity = new UserEntity();
entity.save(user);
public class UserEntity{
   pivate DataBinder<User> dataSet;
   public boolean save(User user){
      return dataSet.save(user);
   }
}

public class DataBinder<T>{
   public boolean save(T table){
      return table.save();
   }
}

使用LitePal的好處就是對象即為表，只需在XML文件中配置好，就可以像是操作對象一樣操作表。

當然，接口返回來的數據不一定能夠完全轉換為表對象，所以需要利用Gson的轉換器Adapter進行轉換。

如果不想在自己的Activity和Fragment中寫轉換代碼，可以自定義Volley的Request，這樣就可以保證Activity和Fragment的代碼更加簡潔清晰。

如果不想這么設計，我們只能采用這樣的流程：

接口數據 ---> Gson ---> Entity ---> Table

其中，Entity就承載了業務操作和數據庫操作，比較重，但Gson這里就簡單多了。

現在的設計是這樣的：

接口數據 ---> Gson ---> Adapter ---> Table

                                                         | （DataBinder)                

                                               ---> Entity

Adapter負責Gson的轉換，Table負責數據庫操作，Entity負責業務操作，而Entity持有Table對象的引用，所需的數據庫操作都通過Table對象，這樣雖然類多了，但職責清晰多了。

當然，這只是我們的嘗試，也許有更好的設計可以取代它。