最近看了FCModel和FMDB的源码，觉得FCModel确实不错，但网上资源不多，因此写下这篇文章，来介绍一下FCModel及自己的理解。
一. FMDB
FMDB是对Sqlite的OC的封装，封装了Sqlite的繁琐的C语言代码，对外提供一些简单的接口，用于操作数据库。FMDB的使用参考唐巧老师的博客，写的很详细 在iOS开发中使用FMDB
二. FCModel
- FCModel在FMDB的基础上，封装了FMDB提供的功能，加入了对象数据模型。它的readme这样介绍的：FCModel是一个操作SQL易取可选择的核心数据模型，CoreData的替代性选择。适用于那些喜欢Core Data的便利性，但又想要对实现、性能、数据库模式、查询、索引、迁移以及使用原始SQL查询等拥有更多掌控的开发者。
它是这样做的，比如查询操作，调用FMDB的查询接口之后，利用运行时的class_getProperty方法和KVC机制构造对象，返回给外部OC对象，而不是FMDB直接返回的数据。 - CoreData也是支持对象的存储的，能够存储OC对象并且从数据库中获取OC对象，它的底层数据库用的是Sqlite。但是CoreData非线程安全，多线程协作很麻烦。FCModel会有内存级的缓存，可以保证多个页面引用的其实是同一个model，保证数据的一致性。FCModel是用信号量机制来控制线程的同步的。
- 下面分析FCModel的源码：
1）FCModel文件夹下包括FCModel、FCModelCacheObject、FCModelDatabaseQueue三个类的.h .m文件。FCModel继承NSObject，在FMDB的基础上，能够更加方便的在数据库中操作自己的对象。
2）FCModel类的主要属性及核心方法作用解释如下图：
+ (NSArray *)allLoadedInstances;
当你使用它的时候，如果其他线程加载了一个新的对象，这个array则已经过期了。这个数组中的东西都是被加载的对象，但是不能保证包括了所有的对象，如果你在不同的线程中使用SELECTs。
+ (void)inDatabaseSync:(void (^)(FMDatabase *db))block;
你可以在相同的数据库对象上随意使用自己的查询操作，他们都会在FCModel的私有数据库操作队列中同步执行。
+ (void)dataWasUpdatedExternally;数据被外部更新
如果在实例外部的任何FCModel表执行INSERT/UPDATE/DELETE，则这个方法会被调用
创建、插入、更新、删除操作。使用信号量机制，控制多线程同步。
static dispatch_once_t token;
dispatch_once(&token, ^{
g_instancesReadLock = dispatch_semaphore_create(1);
g_instances = [NSMutableDictionary dictionary];
});
此处的dispatch_semaphore是GCD用来同步的一种方式，与它相关的共有三个函数，分别是
dispatch_semaphore_create，
dispatch_semaphore_signal，
dispatch_semaphore_wait。
- dispatch_semaphore_t dispatch_semaphore_create(long value);传入的参数为long，输出一个dispatch_semaphore_t类型且值为value的信号量。信号量机制控制线程同步，与OS里面的信号量机制相同
- long dispatch_semaphore_signal(dispatch_semaphore_t dsema)这个函数会使传入的信号量dsema的值加1；
dispatch_semaphore_signal的返回值为long类型，当返回值为0时表示当前并没有线程等待其处理的信号量，其处理的信号量的值加1即可。当返回值不为0时，表示其当前有（一个或多个）线程等待其处理的信号量，并且该函数唤醒了一个等待的线程（当线程有优先级时，唤醒优先级最高的线程；否则随机唤醒）。dispatch_semaphore_wait的返回值也为long型。当其返回0时表示在timeout之前，该函数所处的线程被成功唤醒。当其返回不为0时，表示timeout发生。 - long dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout)；这个函数会使传入的信号量dsema的值减1；
这个函数的作用是这样的，如果dsema信号量的值大于0，该函数所处线程就继续执行下面的语句，并且将信号量的值减1；如果desema的值为0，那么这个函数就阻塞当前线程等待timeout（注意timeout的类型为dispatch_time_t，不能直接传入整型或float型数），如果等待的期间desema的值被dispatch_semaphore_signal函数加1了，且该函数（即dispatch_semaphore_wait）所处线程获得了信号量，那么就继续向下执行并将信号量减1。如果等待期间没有获取到信号量或者信号量的值一直为0，那么等到timeout时，其所处线程自动执行其后语句。
在FCModel中，其中一个线程加载所有实例的时候，创建一个信号量锁g_instancesReadLock，执行wait操作，信号量减一，
NSMapTable *classCache = g_instances[self];
NSArray *instances = classCache ? [classCache.objectEnumerator.allObjects copy] : [NSArray array];执行signal操作，信号量加1.
创建锁的逻辑，放在dispatch_once{}中，只会执行一次。
查看缓存中是否有该实例，执行wait操作，信号量减一。查看该对象是否在缓存中，是否在DB中，查询结束后执行Signal操作，信号量加一。如果某个线程在执行查询缓存操作，另一个线程想要执行查询或创建操作，都需要等待，当信号量为0时，再对它执行wait操作，会进入阻塞状态，等待信号量的释放。
注册新的实例及移除实例，都使用信号量控制同步。
三. FCModel的使用
官网上有使用介绍FCModel
要自己创建一个Model类，一定要继承FCModel，在自己定义的Model类中加入创建数据库及创建表的逻辑，然后使用FCModel中的数据库方法即可方便的完成数据库表的增删改查。
下面举个列子，使用FMDB存取数据和使用FCModel存取数据，通过对比，就可以发现FCModel的便捷之处。
获取数据库中的用户表信息，从数据库中查询之后，需要用dictionary存储起来，再用dictionary去构造user实体。那如果还有其他的很多表对应的实体，比如：部门、user的联系人等等，获取每一个表的信息时都要像下面这段代码这样做，用dictionary存储数据库返回的结果，再用dictionary数据构造对应的实体。同理，数据库存储的时候也是这样，先将实体转成dictionary，再一一存储。这样是不是很麻烦？太多繁琐的重复逻辑的代码。使用FCModel的话，就是在将Dictionary生成实体的时候，使用运行时，生成对象，这样所有的实体都可以用这一个接口来完成dictionary转实体，是不是减少了很多代码？所以，对于有ORM需求的项目，使用FCModel比使用FMDB要好很多。
- (void)getAllUsers:(Complection )completion
{
[_dataBaseQueue inDatabase:^(FMDatabase *db) {
if ([_database tableExists:usersTableName])
{
NSMutableArray* array = [[NSMutableArray alloc] init];
NSString* sqlString = [NSString stringWithFormat:@"SELECT * FROM %@ ", usersTableName];
FMResultSet* result = [_database executeQuery:sqlString];
UserEntity* user = nil;
while ([result next])
{
user = [self userFromResult:result];
[array addObject:user];
}
}
}];
}
- (UserEntity*)userFromResult:(FMResultSet*)resultSet
{
NSMutableDictionary *dic = [NSMutableDictionary new];
[dic safeSetObject:[resultSet stringForColumn:@"name"] forKey:@"name"];
[dic safeSetObject:[resultSet stringForColumn:@"id"] forKey:@"userId"];
[dic safeSetObject:[NSNumber numberWithInt:[resultSet intForColumn:@"Sex"]] forKey:@"sex"];
[dic safeSetObject:[resultSet stringForColumn:@"telphone"] forKey:@"telphone"];
[dic safeSetObject:[resultSet stringForColumn:@"email"] forKey:@"email"];
UserEntity* user = [UserEntity dicToUserEntity:dic];
return user;
}
