老司机出品——数据持久化之基于FMDB的ORM数据库设计
基于FMDB的ORM数据库设计
这次呢，我们来说说iOS中数据持久化的几种方案。说到iOS中的数据存储，无非有4中方式：
- plist
- 偏好设置
- 归解档
- 数据库及其扩展封装
那今天我们就一一展开来讲一下他们各自的优缺点。
plist
这就是我们平时说的Plist文件了，先说下它支持的数据格式。
首先Plist文件支持两种数据格式作为容器，Array及Dictionary。
容器内可以盛放的数据类型主要有Boolean/Data/Date/Number/String。
使用的时候主要是从bundle或者沙盒中读取文件为数组或者字典后取数据。存储的时候也是数组或者字典保存在文件系统中，示例代码如下：
///读取
NSString * path = [[NSBundle mainBundle] pathForResource:@"Info" ofType:@"plist"];
NSMutableDictionary * dic = [[NSMutableDictionary dictionaryWithContentsOfFile:path] mutableCopy];
NSLog(@"%@",dic);
///保存
NSArray * data = @[@1];
NSString * saveP = [NSTemporaryDirectory() stringByAppendingPathComponent:@"arr.plist"];
[data writeToFile:saveP atomically:YES];
NSLog(@"%@",saveP);
Plist的优势呢在于读取和保存过程相对简单，支持的数据类型基本满足需要。
缺点在于呢，不支持模型等特殊数据类型，不支持数据更改，只能够文件覆写。
偏好设置
其实就是我们平常使用的NSUserDefaults。
他呢，支持的数据格式NSString/NSArray/NSDictionary/NSData/NSURL/NSInteger/float/double/BOOL。他的使用方法上跟字典差不多，不过它提供了一些对泛型的支持，示例代码如下：
[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"male"];
BOOL isMale = [[NSUserDefaults standardUserDefaults] boolForKey:@"male"];
值得一提的是，当前NSUserDefaults中做完数据存储后已经不需要再调用-synchronize了。
NSUserDefaults的优势呢在于他同样是过程简单，但是他支持值得更改。缺点是同样不支持模型等特殊数据类型。
归解档
相对于前两种方法，归解档这种方法更适应于模型等特殊数据类型的持久化。想要归解档，你的模型首先要遵循<NSCoding>协议。然后在需要归档或解档的地方直接调用对应方法即可。示例代码：
///类A
@interface A : NSObject<NSCoding>
@property (nonatomic ,strong) NSString * name;
@property (nonatomic ,assign) int age;
@end
@implementation A
-(instancetype)initWithCoder:(NSCoder *)aDecoder {
if (self = [super init]) {
self.name = [aDecoder decodeObjectForKey:@"name"];
self.age = [aDecoder decodeIntForKey:@"age"];
}
return self;
}
-(void)encodeWithCoder:(NSCoder *)aCoder {
[aCoder encodeObject:self.name forKey:@"name"];
[aCoder encodeInt:self.age forKey:@"age"];
}
@end
///调用处
///归档
A * a = [A new];
a.name = @"Wicky";
a.age = 18;
NSString * path = [NSTemporaryDirectory() stringByAppendingPathComponent:@"a.data"];
BOOL success = [NSKeyedArchiver archiveRootObject:a toFile:path];
///解档
if (success) {
A * tmp = [NSKeyedUnarchiver unarchiveObjectWithFile:path];
NSLog(@"%@,%d",tmp.name,tmp.age);
} else {
NSLog(@"fail");
}
另外，在实现两个协议方法时，你也可以通过runtime获取属性列表来自动完成转换，但是你要注意的是，想使用runtime自动转的话，你的所有属性最好都是遵循<NSCoding>的类。
归档的优势在于它支持对象的持久化了而不是那几种特殊的数据类型，悲催的是，你仍需要确保你要归档的属性的数据类型是遵循<NSCoding>的。
数据库及其扩展封装
在iOS中，默认是携带sqlite3数据库的。
我们先来看看sqlite3是什么？
SQLite是一个进程内的库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。它是一个零配置的数据库，这意味着与其他数据库一样，您不需要在系统中配置。就像其他数据库，SQLite 引擎不是一个独立的进程，可以按应用程序需求进行静态或动态连接。SQLite 直接访问其存储文件。
数据库天生就是用来管理多条数据的，所以在数据的增删改查他都占据着得天独厚的优势。而在OC中使用sqlite3目前又主要分为3中方式：
- 使用sqlite3提供的库函数
- FMDB
- CoreData
sqlite3提供的库函数
sqlite3 本身是一套纯C的API，使用起来因人而异，有的喜欢有的不适应。因为不是面向对象的，所以使用起来难免有些冗长。这里我就不放示例代码了，找了一个专门写iOS 原生sqlite3的使用的博客，大家自己看下吧。
嘿嘿
FMDB
FMDB是对sqlite3做的一层对象思想的封装。结构良好，执行效率比原生sqlite3并不逊色。优势在于他是面向对象的。使用教程也是放个链接吧，毕竟一个库使用介绍起来并不是很简明，我就不凑字了。iOS FMDB库详解
他的优势在于他将增删改三个操作都抽象成update方法，查抽象成query方法，在使用上API十分简洁。短板就在于你还是要针对不同模型去组装不同的sql语句。
惯得
CoreData
CoreData是苹果在iOS5之后推出的一款ORM数据库方案，同样他也是针对sqlite3的一种封装。使用它开发者可以只关心数据模型中的数据，而不应考虑数据库中如何操作。他的使用方法我也是扔链接吧。iOS CoreData (一) 增删改查
他的优势在于如果你一开始就使用CoreData搭好一个框架的话，那么在之后的使用中将会减少很多代码量。缺点也很明显，在初次建立映射关系的时候较为繁琐，而且如果是既有工程想做数据迁移的话，也十分麻烦。每添加一个就建议一次映射关系其实也是挺累的。
完犊子
那么有没有一款不用考虑sql语句，你用考虑映射关系，数据迁移一步到位的基于sqlite3的数据库方案呢？当然是有的，要不然老司机为什么在这白话了3618个字符。
有意思
DWDatabase
首先DWDatabase是一套基于FMDB的ORM数据库方案。他的设计理念就是要搞出一套无入侵性的根据模型自动落库的数据库方案。
实现思路大概如下：
- 找出模型中所有需要落库的属性
- 将需要落库的属性类型转换为数据库支持类型
- 落库
所以有了大致思路我们就能以梳理出一套方案：
runtime 获取所有属性并进行动态转换
这其中还是参考了很多YYModel在获取属性时的一些方案，对此由衷的向大神致以崇高的敬意。
他呢，使用起来可以很简单，如下：
BOOL success = [[DWDatabase shareDB] insertTableAutomaticallyWithModel:model name:name tableName:tblName path:path keys:keys error:&error];
这里你的模型甚至不需要做任何兼容，因为一切都是在runtime下动态计算的。
他的优势在于：
- 面向对象
- 无需考虑slq语句的组装
- 无需指定模型与数据表的对应关系
- 无入侵性，现有工程模型无需做修改，直接使用。
- 遵循协议后可自定义ORM映射关系、落库属性黑白名单等。
- 线程安全
目前已知缺点都应经在迭代中完成修复，在后续使用过程中会进行跟进。
好了，扔一个传送门：DWDatabase
欢迎Star、Issue、Pull request。
安排
