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
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操作到任何类中。为减少查询时间并降低内存使用，可使用限制查询中检索到的属性个数的功能。这样其余的属性值可不急于进行加载，直至有必要之时。为允许在开发中截断慢的查询，并查看查询计划，可添加委派代理的方法。这样开发人员可以调整和估量任何已做改进的情况。”
感谢张龙对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。
