@Rays
2016-07-01T12:16:34.000000Z
字数 3247
阅读 1586
Shark是一种新近出现的用于iOS的开源ORM框架,目的在于通过提供高性能与线程安全功能,成为Core Data框架的易用替代者。InfoQ访谈了Spark的创立者,Adrian Herridge。
正如Herridge所述,Shark源于对DBAccess的开发经验。DBAccess是Herridge前期开发的一种用于iOS的ORM,并得到了InfoQ至始至终的关注。Herridge谈及,Shark“具有与DBAccess近乎一致的操作规范”,仅是由于版权的原因,Shark大范围地重构了其代码库。尽管DBAccess是非开源的,但它还是得到了一定规模的应用。Herridge根据开发人员间的相互交流情况、CocoaPod的度量情况和Stack Overflow的提问情况,估计当前大概有700个左右的App使用了DBAccess,这些应用合计约有12,000次下载。
据其创建者所言,Shark的一个强大之处在于其易用性。下面的代码段展示了如何去创建对象,执行查询并通过ORM更新对象,这也是使用Shark的FLUENT API的一个典范。
class Employee: SRKObject {
var name: String?
var age: Int?
}
var newEmployee = Employee()
newEmployee.name = "Steve"
newEmployee.age = 54
newEmployee.commit()
let youngest = Employee.query()
.whereWithFormat("age < %@", withParameters: [21])
.orderBy("age")
.limit(10)
.fetch()
youngest?.lastModified = nil
youngest?.commit()
Shark的后台数据库使用SQLite,支持开发人员执行带有连接和子查询的SQL语句。Herridge指出,这对于开发人员优化应用性能而言是一个十分重要的特性。
线程安全性将会是另一个受Core Data开发人员欢迎的特性。该特性使得在“任何场景下”,Shark所返回的对象得以跨线程使用。
Shark提供的其它卓越特性包括:
为对Shark具有更深的了解,InfoQ与Herridge进行了如下访谈。
你是如何实现从DBAccess项目向Shark项目的转变的?
“我们想要开源DBAccess的动机,纯粹因为我们只有有限的开发时间。越来越多的开发人员联系到我们,并提出在DBAccess项目中添加一些新特性的需求。这些特性我们认为是完全合理的,但是在项目之初并未被我们所考虑到。鉴于项目主版本的开发已经作为一个阶段而结束了,并且该主版本已对我们的所有项目可用了,因此对于项目改进工作我们只能分配很少的时间,而且这些改进对于我们的产品而言并没有任何明显的收益。当前,已有一个足够规模的社区愿意为该项目做出贡献。相对于原项目,我们希望能向更好的方向推进该产品。自开源项目发布以来,我可每周花费至少8个小时在其中,当前对项目的服务支持请求已经显著减少了。
但是我们无法获准去发布我们已经编写好的代码。因而在与我们的CEO讨论之后,我们确定了一个合适的变通方案,就是重写该ORM的代码,并给予新项目一个完全不同的名字。就这样代码重写工作启动了。起始我们将原始代码拿来并重构到不同的源文件中,这使得代码更加模块化。然后对于代码中相对复杂的部分,我们将这些部分从源代码中剥离出来,并在稍后的工作中对这些部分进行重写(例如查询缓存管理器和共享内存系统)。令我们失望的是,这样做的结果对性能改进甚微。
其后,当我们已完成了代码库重构,就开始重写每个函数,并使其与原函数的代码完全不同。这个工作看上去是对每个人的个人时间的一种浪费,但这样做是十分必要,这使得Shark项目与原始项目完全不同,避免了将来可能导致的任何问题。但是在工作复审时,我们发现相对于原来的代码库,新项目依然存在着一些细微的相似之处。注意这里我说的不是一样,而是相似。进而我们做了更进一步的协同开发,去实现代码的模块化,以及有易于二次开发的代码分割。大约在此后一年,尽管还是存在相似之处,新项目已经成为了一个完全不同的代码库。我们已具有了持续测试新方法输入输出的能力,可确保项目的完整性及与DBAccess的兼容性。”
为什么没有选择Swift?
“这个问题很难回答。Swift很明显是未来的发展方向,并且Swift具有足够丰富的特性去完成一个开发任务。但溯本追源,DBAccess需要是静态库,这使得如有必要App可以向后兼容到在iOS6上使用。
在我们启动项目移植时,且就我当时所知,Swift是不能被包含在静态库中的。但是这个原因与我们没有选择Swift是毫不相关的。因为我们当时还达成一个共识,就是开发中只是去使用XCode 7提供的项目模板,而避免去“破解”使用框架所提供的对象。这里XCode模版是生成面向iOS 8及以上版本的动态框架。
该做法中仍然存在的问题是,如果项目是用Swift编写的话,那么Objective-C对象就不能继承于Swift基础类,该基础类从本质而言在我们的项目开发中是无法回避的。
现在代码库已经很好地重构了,我们也面对用Swift编写其中大部分,并最终整个代码库的工作,尤其是考虑到Swift已经是很明显是可取的发展趋势。当前我们已在顶层Swift对象实现上启动了工作,以启用对所有Swift标准数据类型的持久化。”
与DBAccess项目相比,Shark当前的成熟度如何?
“由于Shark采用了按函数依次迁移和模块化的方法构建,我们可对其进行持续测试,整个代码库很少处于不可编译的状态。考虑到Shark项目是基于前期已构建的代码,并且实现了覆盖面更广的测试,虽然它是一个新的项目,但是在很多方面比原DBAccess项目更加可靠。Shark已在文档上比DBAceess更进一步,并且我们正尽可能地对其所有的特性给出更多的例子程序,更加清晰的用法。”
在Shark中,还有哪些你想要强调的高级功能吗?
"对象域管理系统是Shark的一个高级特性。一般情况下,所有对象是各自独立的,并且保存在不同的内存空间中,因而对一个实体的实例所产生的改变只能作用于单一对象上,不能跨越到其它实例中。我们发现在我们的应用开发中,通常情况下这种经深思熟虑的设计决是十分有用的。但是在简单添加了对象域管理功能后,与被改变实例在相同域中的实例就可同时发生改变。域仅是一个字符串值,可在任何时候发生改变,这样设计的强大之处在于,当一个网络线程完成后,为实现对绑定控制的更新而更改其原有的网络域为用户界面域时,你可以同时拥有对包含有对象的网络域和用户界面域的控制。
优化是Shark ORM的另一个关键特性;我们具有用于查询优化的常规工具。为实现更快的数据集检索,可添加索引以及COUNT、SUM和DISTINCT操作到任何类中。为减少查询时间并降低内存使用,可使用限制查询中检索到的属性个数的功能。这样其余的属性值可不急于进行加载,直至有必要之时。为允许在开发中截断慢的查询,并查看查询计划,可添加委派代理的方法。这样开发人员可以调整和估量任何已做改进的情况。”
查看英文原文:Open-Source Shark ORM for iOS Aims to Replace Core Data for High-Performance, Multi-Threaded Apps