Hatena::Groupiphone-dev

haoyayoi Dev Style このページをアンテナに追加 RSSフィード

2010-01-11

CoreDataの構成

| 14:25 | CoreDataの構成 - haoyayoi Dev Style を含むブックマーク はてなブックマーク - CoreDataの構成 - haoyayoi Dev Style CoreDataの構成 - haoyayoi Dev Style のブックマークコメント

サンプルのCoreDataBooksを弄くり通して移植とか試みた結果、どこがどうなってるのかようやく把握できた感じなのでメモ。

そもそも何故分かりづらいのか

CoreDataはSQliteObjective-Cのみで操作できることにメリットがあるわけですが、その操作を行うためのクラス名、取り扱い方に問題があります。

イメージしずらいネーミング

各クラスの解説を読むと判明しますが、実際には他の言語で使われているDBとの接続を行うための各種クラスと、CoreData関連クラスがやってることには、あまり違いはありません。ただ、それらのクラスと余りに剥離したネーミングというのが一つ。

複数のDBの接続を同時に取り扱っている

もう一つは、あくまでCoreDataは「複数のDBとそれらDBとの接続情報」をひとまとめにした代物であるため、他の言語でのDBと同じ感覚で取り扱うとズレが生じるということ。

TableView専用というわけではないNSFetchedResultsController

さらにもう一つ、NSFetchedResultsController自体はCoreDataから取得したデータの配列キャッシュしているコントローラであり、別にUITableViewController専用のオブジェクトではない、ということ。

CoreDataのコンテキスト構成

コンテキスト以下の構成図を貼ってみます。

f:id:hao_yayoi:20100111130810p:image

  • NSManagedObjectModel
    • 他の言語での、DBのColumnとRelationShip指定に相当。
  • NSPersisitentStore
    • DBとの接続を担当。

ColumnもといEntityを追加したい場合にはNSManagedObjectModelへの操作、接続するDBを増やしたい場合にはNSPersistentStoreを追加するといった形です。

NSPersistantStore追加の際の実DBファイル

接続するDBを増やす場合にはNSPersistentStoreを追加するわけですが、実体のファイルもその際に自動で生成されています。

データ追加

f:id:hao_yayoi:20100111135826p:image

NSEntityDescriptionで追加先のEntityを指定すると生成されるオブジェクトレコード相当)に値を入れて保存、という流れです。DBへのレコード追加をSQLを直接触れずに行う形です。

データの読み込み

f:id:hao_yayoi:20100111141156p:image

NSFetchedResultsControllerを生成した時点で、データの取得ができ上がるため、あとは取得したデータの配列からインデックスを指定して取得という流れ。

まとめ

NSManagedObjectContextを構成する際の煩雑さも原因だと思うので、NSManagedObjectContextまでの生成過程を一つのクラスにして分離したほうが、なにかと分かりやすいかと思います。

あと、これらを一つ一つ確かめていくとどこかで同じ構成をみたような感覚があったのですが、PerlにおけるDBIx::Classがそれでした。どんな感じなのかは、

を読むと分かりやすいと思います。