最近在看Android的ORM数据库框架LitePal，就想到可以利用原生的SQLite来实现和LitePal类似的ORM接口实现。
LitePal有一个接口是这样的：
List<Status> statuses = DataSupport.findAll(Status.class);
指定什么类型，就能获取到该类型的数据集合。
这样是很方便，于是想着自己不看它们的实现，自己搞一个出来。
首先想到的就是利用反射和泛型。
利用反射有一个比较好的方式就是注解，读取注解就知道哪些属性是要被赋值的，但现在我还不想使用注解，那该怎么办呢？
我想到了利用反射来调用set方法完成赋值。
首先我们要知道什么字段需要赋值，反射是可以获取到字段，但可惜的是，它无法确定属性的名称和类型，原生的SQLite操作是要知道列名的。
反射是可以知道属性的名字的：
Field[] fields = clazz.getDeclaredFields();
for (Field field : fields) {
Log.e("DatabaseStore", field.getName());
}
Java的Class API有getFields和getDeclaredFields两个方法，前者是用来获取public字段的，后者是用来获取所有声明的字段的，显然必须使用后者，而且注意的是，因为获取到的字段是所有声明的字段，所以绝对有可能获取到不需要的字段。
但光知道属性的名字还是不够的，Android的SQLite需要知道自己要获取到的是什么类型：
cursor.getString(cursor.getColumnIndex("name"));
幸运的是，是可以获取到的：
for (Field field : fields) {
Type type = field.getGenericType();
Log.e("DatabaseStore", type.toString());
}
但如何知道哪些属性是要被赋值的呢？
在代码约束上，我们是可以要求model的所有属性都是要被赋值的，没有道理一个model出现的属性竟然是不需要被赋值的，但实现上，我们还是假设有这样的可能。
这就需要获取到setter，只要有setter，就说明它是需要被赋值的：
List<Method> setMethods = new ArrayList<Method>();
for (Method method : allMethods) {
String name = method.getName();
if (name.contains("set") && !name.equals("offset")) {
setMethods.add(method);
continue;
}
}
这就要求我们所有的属性的setter前面都必须带有set关键字，这同样也是种代码约束。
既然同样都是代码约束，为什么不能直接就是要求属性必须都是要被赋值的呢？
很可惜的是，有可能这个model是需要被序列化的，而序列化有可能会有一个序列ID，序列ID是不需要被赋值的，但又是有可能存在于model中的。
比起这个，只要我们利用编辑器自动生成的setter，是一定会有set关键字的，所以，这种约束更加简单。
接着我们的操作就很简单了：判断Field的名称数组中的元素是否有对应的setter，如果有，就从Field的类型数组中取出该属性的类型，然后判断该类型属于哪种类型，就去表中取出对应的值。
Cursor cursor = Connector.getDatabase().query(clazz.getSimpleName(), null, null, null, null, null, null);//查询并获得游标
List<T> list = new ArrayList<T>();
Constructor<?> constructor = findBestSuitConstructor(clazz);
while (cursor.moveToNext()) {
T data = null;
try {
data = (T) constructor
.newInstance();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
for (Method method : setMethods) {
String name = method.getName();
String valueName = name.substring(3).substring(0, 1).toLowerCase() + name.substring(4);
String type = null;
int index = 0;
if (fieldNames.contains(valueName)) {
index = fieldNames.indexOf(valueName);
type = fields[index].getGenericType().toString();
}
Object value = new Object();
if (type != null) {
if (type.contains("String")) {
value = cursor.getString(cursor.getColumnIndex(valueName.toLowerCase()));
} else if (type.equals("int")) {
value = cursor.getInt(cursor.getColumnIndex(valueName.toLowerCase()));
} else if (type.equals("double")) {
value = cursor.getDouble(cursor.getColumnIndex(valueName.toLowerCase()));
} else if (type.equals("float")) {
value = cursor.getFloat(cursor.getColumnIndex(valueName.toLowerCase()));
} else if (type.equals("boolean")) {
value = cursor.getInt(cursor.getColumnIndex(valueName.toLowerCase())) == 1 ? true : false;
} else if (type.equals("long")) {
value = cursor.getLong(cursor.getColumnIndex(valueName.toLowerCase()));
} else if (type.equals("short")) {
value = cursor.getShort(cursor.getColumnIndex(valueName.toLowerCase()));
}
try {
fields[index].setAccessible(true);
fields[index].set(data, value);
} catch (IllegalAccessException e) {
Log.e("data", e.toString());
}
}
}
list.add(data);
}
cursor.close();
为了保证通用性，使用了泛型，但这里有个小小的问题需要解决，就是如何new一个T?
这不是开玩笑的，因为T是无法new的，所以还是需要通过反射来完成。
通过反射来获取构造器是必须的，但构造器有可能是有很多的，如何获取到最佳的构造器还是个问题。
什么是最佳构造器？
实际上，model的构造器基本上应该是无参构造器，但以防万一，我们还是需要通过一个比较：
protected Constructor<?> findBestSuitConstructor(Class<?> modelClass) {
Constructor<?> finalConstructor = null;
Constructor<?>[] constructors = modelClass.getConstructors();
for (Constructor<?> constructor : constructors) {
if (finalConstructor == null) {
finalConstructor = constructor;
} else {
int finalParamLength = finalConstructor.getParameterTypes().length;
int newParamLength = constructor.getParameterTypes().length;
if (newParamLength < finalParamLength) {
finalConstructor = constructor;
}
}
}
finalConstructor.setAccessible(true);
return finalConstructor;
}
谁的参数最少，谁就是最佳构造器，0当然是最少的。
到了这里，我们基本上就实现了一个拥有和LitePal的API一样但内在实现却是原生方法的数据库接口方法了：
List<Status> newData = DatabaseStore.getInstance().findAll(Status.class);
LitePal当然会提供条件查询的接口，也就是所谓的模糊查询。
模糊查询的基本结构如下：
SELECT 字段 FROM 表 WHERE 某字段 Like 条件
其中，条件有四种匹配模式。
1.%，表示任意0个或更多字符，可匹配任意类型和长度的字符，有些情况下若是中文，就得使用%%表示。
SELECT * FROM [user] WHERE u_name LIKE ‘%三%‘
会把u_name中有“三”的记录找出来。
可以用and条件来增加更多的条件：
SELECT * FROM [user] WHERE u_name LIKE ‘%三%‘ AND u_name LIKE ‘%猫%‘
这样能够找出u_name中的“三脚猫”的记录，但无法找到“张猫三”的记录。
2._，表示任意单个字符，匹配单个任意字符，用来限制表达式的字符长度语句：
SELECT * FROM [user] WHERE u_name LIKE ‘_三_‘
这样只能找出“张三猫”这样中间是“三”的记录。
SELECT * FROM [user] WHERE u_name LIKE ‘三__‘;
这样是找到“三脚猫”这样“三”放在开头的三个单词的记录。
3.[]，表示括号内所列字符中的一个，指定一个字符，字符串，或者范围，要求匹配对象为它们中的任一个。
SELECT * FROM [user] WHERE u_name LIKE ‘[张李王]三‘
这样是找到“张三”，“李三”或者“王三”的记录。
如 [ ] 内有一系列字符（01234、abcde之类的），则可略写为“0-4“，“a-e”：
SELECT * FROM [user] WHERE u_name LIKE ‘老[1-9]‘
这将找出”老1“，”老2“。。。等记录。
4.[^]，表示不在括号所列之内的单个字符，其取值和[]相同，但它要求所匹配对象为指定字符以外的任一个字符。
SELECT * FROM [user] WHERE u_name LIKE ‘[^张李王]三‘
这样找到的记录就是排除”张三“，”李三“或者”王三“的其他记录。
5.查询内容包含通配符。
如果我们查特殊字符，如”%“，“_"等，一般程序是需要用"/"括起来，但SQL中是用"[]"。
知道了这些基本的知识后，我们就可以开始看LitePal的接口是怎样的：
List<Status> myStatus = DataSupport.where("text=?", "我好").find(Status.class);
这样的接口比较简单，并且允许链式调用，形式上更加简洁。
要想实现这个，倒也不难，我们暂时就简单的用一个condition的字符串表示要查询的条件，然后提供一个where方法实现where查询的拼接，暂时就只是单个条件：
private String conditionStr;
public DatabaseStore where(String key, String value) {
conditionStr = " where " + key + " like ‘%" + value + "%‘";
return store;
}
为了实现链式调用，返回DatabaseStore是必须的。
接下来就非常简单了，只要拼接完整的SQL语句，然后执行就可以了：
public <T> List<T> find(Class<T> clazz) {
String sql = "SELECT * FROM " + clazz.getSimpleName().toLowerCase() + conditionStr;
Cursor cursor = Connector.getDatabase().rawQuery(sql, null);
Field[] fields = clazz.getDeclaredFields();
List<String> fieldNames = new ArrayList<String>();
for (Field field : fields) {
fieldNames.add(field.getName());
}
List<Method> setMethods = getSetMethods(clazz);
List<T> list = getList(clazz, cursor, setMethods, fieldNames, fields);
cursor.close();
conditionStr = "";
return list;
}
getSetMethods方法就是上面获取setter的代码的封装，而getList方法就是上面生成指定类型对象的List的代码的封装。
这样我们的接口方法的调用就是这样的：
List<Status> data = DatabaseStore.getInstance().where("text", "我好").find(Status.class);
无论是LitePal还是我们自己的实现，where都必须放在find前面。
这里倒有一个小贴士可以说说，就是获取数据库所有表名的操作。
由于底层我们还是使用LitePal来建表，而LitePal的建表非常简单，就是在assets文件夹下面放一个litepal.xml文件：
<?xml version="1.0" encoding="utf-8"?>
<litepal>
<!-- 数据库名称 -->
<dbname value="xxx.db"></dbname>
<!-- 数据库版本 -->
<version value="1"></version>
<!-- 数据库表 -->
<list>
<mapping class="com.example.pc.model.Status"></mapping>
</list>
</litepal>
但表名具体到底是啥呢？
为了确认一下，我们可以查询数据库中所有的表的名字：
Cursor cursor = Connector.getDatabase().rawQuery("select name from sqlite_master where type=‘table‘ order by name", null);
while (cursor.moveToNext()) {
//遍历出表名
String name = cursor.getString(0);
Log.e("DatabaseStore", name);
}
每一个SQLite的数据库中都有一个sqlite_master的表，这个表的结构如下：
CREATE TABLE sqlite_master ( type TEXT, name TEXT, tbl_name TEXT, rootpage INTEGER, sql TEXT );
对于表来说，type字段是”table“，name字段是表的名字，而索引，type就是”index“，name是索引的名字，tbl_name则是该索引所属的表的名字。
不管是表还是索引，sql字段是原先用CREATE TABLE或者CREATE INDEX语句创建它们时的命令文本，对于自动创建的索引，sql字段为NULL。
sqlite_master表示只读的，它的更新只能通过CREATE TABLE，CREATE INDEX，DROP TABLE或者DROP INDEX命令自动更新。
临时表不会出现在sqlite_master中，临时表及其索引和触发器是存放在另外一个叫sqlite_temp_master的表中，如果想要查询包括临时表在内的所有的表的列表，就需要这样写：
SELECT name FROM (SELECT * FROM sqlite_master UNION ALL SELECT * FROM sqlite_temp_master) WHERE type=’table’ ORDER BY name
LitePal还可以对结果进行排序：
List<Status> myStatus = DataSupport.where("text=?", "我好").order("updatetime").find(Status.class);
这个也是很简单就能实现的，类似where方法一样的处理：
public DatabaseStore order(String key) {
conditionStr += " order by " + key;
return store;
}
默认是升序。
API被人乱用的概率相当大，这时就需要有一些错误提示帮助用户定位问题了，最简单的例子就是在没有任何条件的情况下调用find方法，这时就应该提示没有任何条件：
if (conditionStr.equals("")) {
throw new Throwable("There are not any conditions before find method invoked");
}
还有一种情况并不算是被乱用，但按照上面的实现是会出错的：
statuses = DatabaseStore.getInstance().order("updatetime").where("text", "我好").find(Status.class);
绝对会报错，因为最后的SQL语句是这样的：select * from status order by updatetime where text like ‘%我好%‘。
这是不对的，必须将where放在order by前面。
解决这个问题的方法就是提供两个字符串：
private String whereStr = "";
private String orderStr = "";
public DatabaseStore where(String key, String value) {
whereStr += " where " + key + " like ‘%" + value + "%‘";
return store;
}
public DatabaseStore order(String key) {
orderStr += " order by " + key;
return store;
}
接着就是在find方法中进行判断：
if (whereStr.equals("") && orderStr.equals("")) {
throw new Throwable("There are not any conditions before find method invoked");
}
String sql = "select * from " + clazz.getSimpleName().toLowerCase() + (whereStr.equals("") ? "" : whereStr) + (orderStr.equals("") ? "" : orderStr);
暂时就简单实现了类似LitePal的ORM接口调用形式。