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对象，这样虽然类多了，但职责清晰多了。

固然，这只是咱们的尝试，也许有更好的设计能够取代它。