最近开发的一个项目主要有两个特点，这两点也是在项目开发前需要着重去规划解决方案的：
- 需要和Rest服务端请求大量的数据
- 同时这些数据本地也要保存到sqlite数据库
对于第一点，目前的Volley、Gson等框架既可以解决从服务端请求数据拉下Json数据并解析成java对象的全过程。但是对于第二点，就有点头疼了。按照以往的开发模式，我们要写一些操作sqlite数据库的代码，同时可能还需要用到什么查询数据库绑定到view上的东西，这里想到了很多Android提供的类：SqliteDataBase、DataHelper、CursorAdapter或者ContentResolver等等太多了，连我自己都弄不清了，每次做到这里都要去查一些原来的代码和网上资料
我们知道，那些长期的重复的代码，必将会被总结成一套简单的框架。那么对于保存数据库和取出数据这块，是否有更好的更简单的方式或者框架呢？答案是有的，就是SugarORM框架
SugarORM简介
要说SugarORM之前不得不说ORM。ORM（Object-Relational Mapping）即对象关系映射模式，是Java开发中常用的技术。它的作用是在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。因为Android开发也是用Java语言，所以Android平台上涌现了一些Android的ORM框架，比如ORMLite、GreenDao、SugarORM，ORMLite并不是专为Android打造的，GreenDao据称性能比较高，但是有重大的缺陷，这里后面会说到。所以最后选用了SugarORM这个框架，同时SugarORM一直在更新维护，所以也推荐使用这个框架。
它具有下列优点：
- 不用写复杂的sql语句，而用简单的API即可完成创建和操纵数据
- 可以在原有的Bean上仅仅添加小的修改而复用Bean
- 简化而明了的数据库设计和创建过程，同时提供表的一对多的支持
SugarORM在github上的官网为：
SugarORM的操作
通过在gradle中添加下列依赖来导入SugarORM:
compile 'com.github.satyan:sugar:1.3'
在你的自定义Application类的onCreate和onTerminate中分别加上
SugarContext.init(this);
SugarContext.terminate();
同时在AndroidManifest.xml中的Application元素中添加下列meta-data:
<applicationandroid:label="@string/app_name"android:icon="@drawable/icon"
android:name="com.orm.SugarApp">
.
.
<meta-dataandroid:name="DATABASE"android:value="sugar_example.db"/>
<meta-dataandroid:name="VERSION"android:value="2"/>
<meta-dataandroid:name="QUERY_LOG"android:value="true"/>
<meta-dataandroid:name="DOMAIN_PACKAGE_NAME"android:value="com.example.bean"/>
.
.
</application>
四个meta-data分别确定了：
- 创建的数据库db的文件名，将在/data/data/{你的应用包名}/databases下创建对应的文件
- 数据库版本号
- 是否允许SugarORM记录log
- 创建数据库表对应的Bean所在的包的路径
对于第四点需要强调一些，SugarORM是通过一个Bean文件来创建一个表的，比如你想在sugar_example.db中创建一个叫做Goods的表，那么你需要在上面你规定的com.example.bean中创建一个Goods.java的Bean文件，然后你编译运行的时候，会自动在db中创建了这个空表
这里具体说明细节：
比如你的Goods.java需要这么写：
public class Goods extends SugarRecord implements Serializable {
/**
* 货品编号
*/
@Column(name = "sku_ID", unique = true)
@Expose
private String skuId;
/**
* 商品编号
*/
@Expose
private String spuId;
/**
* 规格
*/
@Expose
@Ignore
private String specValue;
/**
* 货品名称
*/
@Expose
private String name;
/**
* 货号
*/
@Expose
private String bn;
/**
* 成本价,进价
*/
@Expose
private BigDecimal cost;
/**
* 售价
*/
@Expose
private BigDecimal price;
public String getSkuId() {
return skuId;
}
public void setSkuId(String skuId) {
this.skuId = skuId;
}
public String getSpuId() {
return spuId;
}
public void setSpuId(String spuId) {
this.spuId = spuId;
}
public String getSpecValue() {
return specValue;
}
public void setSpecValue(String specValue) {
this.specValue = specValue;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getBn() {
return bn;
}
public void setBn(String bn) {
this.bn = bn;
}
public BigDecimal getCost() {
return cost;
}
public void setCost(BigDecimal cost) {
this.cost = cost;
}
public BigDecimal getPrice() {
return price;
}
public void setPrice(BigDecimal price) {
this.price = price;
}
}
这是一个描述一个商品的Bean，Sugar会自动的在db中创建Goods这个表，表中的字段和Goods.java中的属性名对应，这里注意几点：
- Bean的属性名所采用驼峰命名法，那么大写的字母会在创建的表中字段转换成下划线。比如spuId这个属性对应的表中的字段名为spu_id
- 之所以实现Serializable是因为这个Bean在代码中不仅仅为SugarORM创建表而服务，同时也是为了能在Android组件中传递（比如Handler中的message.obj）而用，所以这里和官网的直接继承自SugarRecord<T>不同，推荐大家用我这种方式
- @Column这个注解意思是说你想强制按照你的规定的名字来创建表中对应的字段名字，所以这里的skuId在Goods表中的字段名就不是默认的sku_id了，而是你自己给的sku_ID
- @Expoes是来自于Gson的的一个注解，后面会说到
- @Ignore这个注解强调这个属性在表中不要创建对应的字段
SugarORM通过save()，delete()，T.findbyid()，T.listAll()等API来简化数据库的增删改查操作：
增加一条数据：
Goods good = new Goods();
good.setName("Coffee");
good.setCost(new BigDecimal(30));
good.setBn("123456");
good.save();
查询一条数据：
Goods loadGood =Goods.findById(Goods.class,1);
查询所有的表中的条目：
List<Goods> goods =Goods.listAll(Goods.class);
更新一条数据
:
Goods good2 = Goods.findById(Goods.class, 1);
good2.setName("Rice");
good2.save();
删除一条数据：
Goods good2 = Goods.findById(Goods.class, 1);
good2.delete();
删除表中所有的条目：
Goods.deleteAll(Goods.class);
SugarORM的条件查询操作
可以直接通过提供的find和findWithQuery进行查询：
Goods.find(Goods.class, "name = ? and skuId = ?", "Coffee", "123");
如果你有其他的比如groupby、orderby、limit等操作，具体的find的接口格式为：
find(Class<T> type, String whereClause, String[] whereArgs, String groupBy, String orderBy, String limit)
通过findWithQuery接口查询：
List<Note> notes = Note.findWithQuery(Note.class, "Select * from Note where name = ?", "satya");
SugarORM同时提供了条件查询的API，叫做Query Builder，目前还处于Beta版本：
Select.from(TestRecord.class)
.where(Condition.prop("test").eq("satya"),
Condition.prop("prop").eq(2))
.list();
SugarORM的一对多使用
通常开发中，一个表中的某个字段对应了另一个表，这个在java类中体现的就是一对多的关联的关系，这里SugarORM也是支持的。比如Goods表中有一个Operator的字段，它说明了负责这个商品的人
public class Operator extends SugarRecord implements Serializable {
String userName;
String gender;
public String getUserName() {
return userName;
}
public void setUserName(String userName) {
this.userName = userName;
}
public String getGender() {
return gender;
}
public void setGender(String gender) {
this.gender = gender;
}
}
在Goods.java中可以加上这个Operator的属性，那么Goods表即也会加上这样的字段
：
public class Goods extends SugarRecord implements Serializable {
...
private Operator operator;
public Operator getOperator() {
return operator;
}
public void setOperator(Operator operator) {
this.operator = operator;
}
...
}
下面是查询的方式：
List<Goods> goods = Goods.find(Goods.class, "operator = ?", new String{operator.getName()});
或者
Goods good = Goods.findById(Goods.class, 1);
Operator o = good.getOperator();
SugarORM中Bean可复用Gson的Bean
SugarORM最大的好处是，用于创建表的Bean是你自己可以定义的，这点相对于GreenDao而言是不言而喻的。GreenDao是自动帮你创建了bean类，但是如果这个Bean你又需要用来解析网络拉下来的Json数据，那么就有问题了。
我们知道Gson也是通过Bean对象来解析Json数据的，但是Gson支持在Bean中的属性上加一些注解（比如@Expose这个注解）。那么这里你可能想到解析Json所用的bean和储存数据库所用的bean能共用，那么这里的存储数据库的bean因为需要加一些gson或者别的框架的注解，就不能让ORM框架来自动生成了。所以， GeenDao没法使用。
开发中注意的地方
- 命令问题
- 数据库更改的问题
第一个问题是本文开头所提到的“Bean的属性名所采用驼峰命名法，那么大写的字母会在创建的表中字段转换成下划线”这个问题，从SugarORM公布的源码里面能看到它是自己加上的"_"而并不是一个bug，这里可能是为了想和java web的一些开发方式保持一致吧，或许是为了规避sqlite对大小写敏感而导致的各种问题而引入的这种策略。所以开发者在用SugarORM的时候要注意命名的改变。你在Bean中写了一个属性名，而数据库中的字段名并不是这个。当然了，这里可以通过@Column注解来搞定
第二个问题是一个习惯性问题。开发中由于不用直接操作SqliteDataBase这种类型的类了，所以多人同时开发的时候某个人提交代码的时候只是修改了他所负责的表的对应的Bean的结构，而这个时候你再更新代码在重新安装Apk后会发现报错，比如找不到某个表的字段的错。这个是因为表结构改了，所以你不得不先卸载原来的应用而重新安装apk。所以这里最好在多人开发的时候养成一个习惯：某个人修改了某个Bean后（即更新了表结构）一定要通知其他人