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對象，這樣雖然類多了，但職責清晰多了。

固然，這只是咱們的嘗試，也許有更好的設計能夠取代它。