首页 > 代码库 > LitePal + Gson + Volley的ORM框架尝试方案
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对象,这样虽然类多了,但职责清晰多了。
当然,这只是我们的尝试,也许有更好的设计可以取代它。
LitePal + Gson + Volley的ORM框架尝试方案
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。