基于ORM思想的数据库处理

本文主要是介绍iOS上数据库存储方案,利用ORM对FMDB做一层封装,让代码更加简洁方便。

一、数据库开发的蛋疼问题

有了FMDB对sqlite 的封装,iOS端的数据库操作相当方便,我们再也不用面对那些磨人的线程问题和蛋疼的sqlite。但是在实际开发中仍无法避免的遇到一些蛋疼问题。

这是简单的创建一张表,我想你看到这样的代码都要发疯。然而更让人发疯的是某天因为产品的需求我们需要增加一个字段,那我们不得不在在各个地方改啊改。而一旦因为疏忽数据库升级没有处理好,就可能造成很严重的线上事故。(很遗憾我就遇到了这种事故)

二、如何解决这种问题

2.1 Key-Value式的存储 - YTKKeyValueStore

iOS客户端的数据表往往还要对应一个Model,这导致在使用时还要加层Model转化,而移动端对于数据库的查询要求并不高,针对这些特点Key-Value式的存储应运而生。比较代表性的框架有 猿题库的 YTKKeyValueStore(主要思路是将数据模型进行序列化做为Value存储)。但是这类框架的缺陷也相当明显,只能通过主Key查询。而且如果模型发生变化,数据升级处理也只能放在 模型转换时处理。Key-Value式的存储实际上已经不能称之为数据库存储了,它是根据客户端的特殊需求而产生的一种特殊产物,数据库对它而言只是一种容器。

2.2 ORM框架-GYDataCenter

ORM(Object Relational Mapping)框架采用元数据来描述对象一关系映射细节,元数据一般采用XML格式,并且存放在专门的对象一映射文件中。只要提供了持久化类与表的映射关系,ORM框架在运行时就能参照映射文件的信息,把对象持久化到数据库中。当前ORM框架主要有四种:Hibernate(Nhibernate),iBATIS,mybatis,EclipseLink。
以上是百度百科对ORM框架的解释,大家注意我标注的两个关键词,运行时以及对象,iOS客户端的数据库存储本质就是要将一个对象存储到数据库,而OC也正是一种运行时语言,我们要做的就是建立一个映射文件,在运行时参照映射文件产生对应sql语句将对象保存到数据库。

MLeaksFinder这个框架我想不少同学都不陌生,它采用了一种很巧妙的方式,让我们在DEBUG模式下可以轻松的发现内存泄漏问题。今天我逛作者 Zepo 的gitHub时发现他又写了另外一个框架GYDataCenter我简单的看了一下它正是采用ORM思想写的一款iOS客户端的数据库存储方案,与我的想法不谋而合。

我并没有看GYDataCenter的源码,只是根据使用方式提出一些问题。GYDataCenter的 映射关系 是通过GYModelObject提供相应方法来提供,而使用必需继承GYModelObject实现对应方法。也就是说作者将 映射关系 与 对象模型 合在了GYModelObject类,造成了耦合。这种耦合会造成一些问题,在项目中 模型使用的地方太多,模型转换,view展示,数据处理都要涉及到模型将 映射关系 加到模型中很容易导致模型的臃肿。而继承关系的使用也使得入侵性太强。所以说 映射关系 应该独立于对象 模型存在。

三、JYDatabase(铺垫了那么多这才是我要讲的……)

JYDatabase 这是本人基于ORM思想写的一款数据库应用框架,和GYDataCenter一样也是基于FMDB实现的,下面主要讲一下框架的实现和使用。

3.1 要解决的问题

3.2 数据表的建立(映射关系的建立)

数据表的建立需要继承 JYContentTable(该类实现了工作中用到的大部分SQL查询),只要重写以下几个方法就可以快速创建一张数据表。

3.3数据库的创建和升级管理

3.3.1数据库的创建和升级管理类需要继承JYDataBase

3.3.2数据库升级的实现- (void)updateDB:(FMDatabase *)aDB

3.4条件查询的实现

}

四、结尾

关于JYDatabase的使用和介绍 大家可以去gitHub查看更详细的说明
https://github.com/weijingyunIOS/JYDatabase,关于上面介绍的框架大家可以根据实际需要做下对比后选择使用。 GYDataCenter 是相当不错的数据库处理方案,如果它早点出来或者我早点看到也许就不会花费大量精力去写JYDatabase了,不过写JYDatabase也是很愉快的因为它的思路走向是根据我自身遇到的痛点来写的,比如sql查询,就是因为sql语句可能就是因为一个关键位置的空格问题导致无法执行,所以我专门写了个JYQueryConditions来弱化sql。

2 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部