iOS的开源ORM Shark：以高性能、多线程的开发去替代Core Data

　　英文原文：Open-Source Shark ORM for iOS Aims to Replace Core Data for High-Performance, Multi-Threaded Apps

      github: https://github.com/birthmark/sharkorm

　　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 的一个典范。

　　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 操作到任何类中。为减少查询时间并降低内存使用，可使用限制查询中检索到的属性个数的功能。这样其余的属性值可不急于进行加载，直至有必要之时。为允许在开发中截断慢的查询，并查看查询计划，可添加委派代理的方法。这样开发人员可以调整和估量任何已做改进的情况。”