导语
LeanCloud上半年开源了客户端SDK代码不久，笔者就开始留意阅读其中的代码，不出意料，因为API之前很多借鉴了ParseSDK，所以看内部实现也多少有些Parse的影子，笔者也将两者的SDK代码比较看过，本文先从几个核心概念的角度大致过一遍LeanCloud数据服务SDK；
Pre
因为属于Baas行业的SDK产品，这里先不具体赘述，你只需要知道提供给开发者的是后端云平台和客户端SDK，而区别于传统的数据库而言，他是无模式的，也就是数据库表结构后期可以动态调整的；
Main
SDK初始化
在后端创建好应用之后获取到appid和appkey，并一次传入门面类AVOSCloud的initializw方法中，值得说的一点是，只要登录过官网，页面的文档中代码的这两个参数都显示好了，无需额外复制；
这里说下为什么很多SDK(开放平台接口)都需要初始化，而基本都需要传官网下发的AppId：因为平台需要一个唯一标识App的字符串，很多请求均需要携带该参数，所以可以在init时候由SDK保存后续拼接请求让SDK自行添加即可，或者SDK内部一些准备操作，而一般初始化都是建议越早越好，约定俗成是在Application的onCreate方法中，SDK你也可以在此时拿到主线程的Handler,方便后续做耗时操作后切换到主线程去回调Api的方法如onSuccess等;
核心类AVObject
说AVObject为核心类并不为过，在这里你需要先知道后端习以为常的ORM概念，或许你用过一些Android平台的ORM库如ActiveAndroid,GreenDao等，这样的话，客户端的一个类就对应后端数据库的一张表，类中的字段映射到表中的字段，一个对象就代表表的一个记录，这种ORM的方式和你用过的ORM库的区别在于，映射的范围是从客户端映射到后端服务器，因为需要经过网络耗时操作，所以需要异步接口回调，后续你也看到比如AVObject的save方法带有一个类似SaveCallback的回调类(一般都是抽象类，好扩展)，当然，笔者觉得，LeanCloud的SDK并不是标准意义上的ORM实现，更接近一些的是另一个用户量也很多的平台–Bmob，这两种实现方式各有优点；
现在说说AVObject：
创建一个目标对象比如Coder，并设置一些字段和属性值：
AVObject coder = new AVObject("Coder");
coder.put("name","宸笙");
coder.put("address","guangzhou");
// 保存
coder.saveInBackground(new SaveCallback(){
@Override
public void done(AVException e){
if(e == null){
// ...保存成功
}else{
// ...
}
}
});
是不是比较简单？
一些疑问：
- 需要先在后端控制台(类似于可视化的数据库查看操作界面如WorkBentch)建好表和字段吗？
不需要，后端自行创建；
- 后续需要新增字段怎么办？– 直接多put一个属性即可；
coder.put("job","SDK Developer"); - 对数据类型的支持如何，复杂点的呢，还有，后端数据库不是有表和表的关联吗？
基本支持不同基础类型和数组，文件等，数据关联基本分Pointer和Relation两大类；
- 数据的增删查改都在该类中吗？
一般新增和修改数据这种高频操作通过
AVObject可以，而查询是更高频的操作，特别是一些复杂查询，所以单独抽出来作为一个AVQuery类； - 数据库有常见的写sql语句吗，直接执行一些就好了
支持常见sql；
到这里，你可能也猜到了，原则上，所有数据库的表都能用这个AVObject指代了，这里你可能需要了解几个系统字段，也就是不用开发者指定的，它们是：
-
objectId-
唯一标识数据库中的一条记录，你可以暂时把它理解为类似uuid，实际有的厂商也是这么实现的；
-
插入(保存)成功后会得到objectId；
-
可以指定objectId查询对应的记录信息；
-
-
createdAt指代记录的创建时间；
-
updatedAt指代对象被修改的时间；
通过后面两个字段你也可以指定查询结果中的排序方式，比如指定通过创建时间排序等；
批量操作
如果同个表的多个字段要保存是不是很麻烦呢，相应的需要爱批量操作的功能，可以把所有对象添加到集合中，调一次API请求就可以了，而这样也能节省开发者很多请求数；
save or saveInBackground
前面那种有回调函数的风格是当开发者需要知道操作成功的点去做进一步的处理，如果开发者并不关心呢，那可以直接调用save方法。
AVUser
毫无疑问，用户的登录注册模型是众多App公有的，那么有没有可能把这部分也做好并提供给开发者复用呢，是可以的；
-
AVUser和AVObject的关系可能有的读者理解是：用户表不也是一张表吗？ 是的，但是用户表可能比较特殊，因为不同用户能看到的数据可能是不同的(比如分级别的用户体系)，这张表的数据用户不能随便修改(比如用户A肯定是不能修改同一级别的用户B的信息的)，这些需要后端保障，当然在SDK实现上可以是Object的子类，比如
BmobUser和BmobObject的关系，而实际上，用户表中一些默认常用字段可以是SDK预先定义好的，比如用户名，密码，是否通过手机号或邮箱验证等，当然，也要提供可扩展；另外一个值得注意的是，用户类中的一些特定方法如
注册(当然你可以理解为也是一种插入)，登录， (不同登录方式)，重置密码等都是用户表独有的，所以单独抽取出来一个AVUser还是很有必要的； -
token
AVQuery
TODO
ACL
简单说，为了支持不同角色对不同数据的读写权限的控制而提供的功能，这里的粒度细化到了每一行记录；
数据关联
TODO
