Shark(iOSのためのオープンソースORM)はハイパフォーマンスとマルチスレッド対応を強みとし、Core Dataの置き換えを目指す

Sharkは、iOS用の新しい、オープンソースORMフレームワークである。 SharkはCore Dataに対する置き換えを狙っており、ハイパフォーマンスとスレッドセーフティを提供する。 InfoQは、Sharkの開発者であるAdrian Herridge氏と対談した。

Herridge氏によると、Sharkは、DBAccess開発の経験を元に生まれたとのことである。 DBAccessは、氏が以前に開発したiOS用のORMである。 InfoQでは、DBAccessがローンチされた際、これを取り上げている。 Sharkは、DBAccessと“同一の仕様を保っている”とHerridge氏は語る。 しかし、コードベースは著作権の問題を理由として大幅に書き換えられた。 DBAccessは、クローズドソースではあったが、大変な反響を呼んだ。 Herridge氏によると、700を超えるアプリケーションに採用された(開発者からの連絡、CocodPadメトリクス、およびStack Overflowの質問を元に計測したもの)。 さらに、1万2千回以上ダウンロードされた。

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は、DBエンジンとしてSQLiteを使用する。 このため、開発者は結合や副問い合わせを含むSQLクエリを実行できる。 これは、開発者がアプリケーションのパフォーマンスを最適化する際に助けになる、とHerridge氏は語る。

Core Data開発者にとって喜ばしい、もう一つの機能は、スレッドセーフティである。 これにより、Sharkが返すオブジェクトは、“どのような状況でも”スレッドをまたいで使用できる。

Sharkがもたらす、その他の特徴的機能は以下の通りである。

• トランザクション
• イベントモデル
• 列レベル暗号化
• バッチ処理のサポート
• オブジェクト管理を制御するためのオブジェクトドメイン

InfoQは、Sharkの詳細について、Herridge氏に質問した。

DBAccessからSharkへの転換はどのように行われたのですか?

時間が経つにつれ、オープンソース版のDBAccessを求める気持ちは、自然と高まりました。 開発者たちは、私たちにコンタクトをしてきて、より良い機能に対しての要望を出してきました。 それは、私たちが当初考えていたものとは違うものでした。 全てのプロジェクトに対して有益となるように開発を行うことを目指していたため、 私たちのプロダクトに対して明確な利益とならないように思えることに対してまで、 改善をする余裕がなくなっていきました。 十分に大きなコミュニティを抱えた状況で、オリジナルを超えるプロダクトを作り出そうとしていたのです。 リリース以降、私は週に最低8時間、このプロジェクトのために作業しています。 現在は、質問サポートは大幅に減少しました。

私たちは、すでに書いたものに対する再リリース提案を受けることができません。 そこで、CEOと相談をしたのち、私たちはORMの書き直しを決定しました。 この時、現在のプロダクト名とは全く違う名前にするのが良い、ということになりました。 書き直しが開始された当初、私たちはオリジナルのコードをリファクタリングし、ソースファイルを分割して、モジュール化していました。 そのあと、複雑な箇所を切り離し、後で作りこめるようにしました(クエリ・キャッシュ・マネージャや共有メモリシステムなどです)。 予想はしていましたが、これではパフォーマンスの向上はほとんどありませんでした。

そこで、私たちはコードベースを再編成し、全ての関数を書き直しました。 これは、各個人の時間の浪費に感じられましたが、オリジナルプロジェクトから脱却するには必要だったのです。 これにより、将来発生するであろう問題を回避できました。 しかし、作ったものをレビューすると、まだ元のコードベースと殆ど同じでした。 まったく同じではないものの、よく似ていたのです。 ですので、さらにコードをモジュール化し、簡単に再開発できるようにするための分割をする試みがなされました。 ほぼ1年後には、まだ同様な箇所は残っていましたが、非常に違ったコードベースになりました。 ここにいたり、私たちは、新しいメソッドに対する、入出力の継続的テストを付け加えました。 これは、DBAccessに対する整合性、互換性を保証するために行ったものです。

なぜSwiftではないのですか?

これに答えるのは難しいですね。 将来に関する話ですし、このタスクの将来性は十分にあると考えていますので。 ただし、基本的に、DBAccessはスタティック・ライブラリでした。これは、iOS 6のバックエンドとして使えるようにするための措置でした。

私たちが移植を開始したころ、私の知る限り、Swiftはスタティック・ライブラリをインクルードできませんでした。 ただし、これは本筋の話ではありません。私たちは、フレームワークを“ハック”せずに、単にXCode 7のテンプレートを使って、iOS8+用の動的フレームワークを生成するという判断も行いました。

Swiftで書かれた場合に残る問題は、Objective-CのオブジェクトがSwiftの基底クラスを継承できないことです。 これこそ、私たちの仕事が止まってしまう理由でした。

現在、コードベースは適切に分離されています。 私たちは、かなりの量をSwiftで書くことになると予想しています。 もしそれが望ましいとわかれば、全体を書き直すこともあり得ます。 私たちはすでに、トップレベルのSwiftオブジェクトを標準のSwiftデータタイプに永続化するための作業を始めています。

DBAccessと比較して、Sharkの完成度はどの程度ですか?

関数単位の移植や、Sharkのモジュール化により、すでにテストできるようになっています。 コンパイルできないコードベースは殆どありません。 新プロダクトでありながら、よくこなれたコードをベースとしており、様々な点で、より良いテストカバレッジを出しています。 さらに、今回は、文書も前回より充実しています。 加えて、全機能に対して多くの例を提供しており、解説も可能な限り行っています。

あなたがお勧めする、Sharkのアドバンストな機能はなんですか?

Sharkのアドバンストな機能の一つは、マネージド・オブジェクト・ドメイン・システムです。 標準では、全てのオブジェクトは独立しており、別々のメモリ空間に存在しています。 ですので、1つのエンティティに対応するインスタンスへの変更は、1つのオブジェクトにのみ影響を与えます。 変更が、他のインスタンスにおよぶことはありません。 これは堅実な設計判断です。 この考え方が、アプリケーション開発において、非常に有効であることを私たちは知っています。 しかし、マネージド・オブジェクト・ドメインを単純に追加するだけで、同じドメイン内の他のインスタンスを一度に更新することができるようになります。 ドメインは単なる文字列であり、いつでも変更できます。 これの利点は、あなたが、ネットワーク・ドメインやUIドメインを設定し、オブジェクトを結びつけたときに表れます。 ネットワークスレッドが完了した時、ドメインの状態が更新され、さらに束縛されたコントロールを更新するよう、UIドメインを変更するということを可能にします。

最適化も、このORMの重要な機能です。 私たちは、使い慣れたツールを使って、クエリを最適化できます。 インデックスはどのクラスにも追加できます。 高速なデータセット取得のため、COUNT、SUM、DISTINCT演算子を使用できます。 クエリから取得したプロパティに対して、制限をかけることもできます。 これは、時間短縮と、メモリ効率改善に有効です。 取得されなかったプロパティは、必要になった時点で、遅延ロードされます。 委譲メソッドの追加により、開発中にスロークエリが発生した場合、割り込みをかけることができます。 実行計画の確認もできるので、修正に対しての改善度合いを測定することができます。