2010-01-11
CoreDataの構成
CoreData | | 
サンプルのCoreDataBooksを弄くり通して移植とか試みた結果、どこがどうなってるのかようやく把握できた感じなのでメモ。
そもそも何故分かりづらいのか
CoreDataはSQliteをObjective-Cのみで操作できることにメリットがあるわけですが、その操作を行うためのクラス名、取り扱い方に問題があります。
イメージしずらいネーミング
各クラスの解説を読むと判明しますが、実際には他の言語で使われているDBとの接続を行うための各種クラスと、CoreData関連クラスがやってることには、あまり違いはありません。ただ、それらのクラスと余りに剥離したネーミングというのが一つ。
複数のDBの接続を同時に取り扱っている
もう一つは、あくまでCoreDataは「複数のDBとそれらDBとの接続情報」をひとまとめにした代物であるため、他の言語でのDBと同じ感覚で取り扱うとズレが生じるということ。
TableView専用というわけではないNSFetchedResultsController
さらにもう一つ、NSFetchedResultsController自体はCoreDataから取得したデータの配列をキャッシュしているコントローラであり、別にUITableViewController専用のオブジェクトではない、ということ。
CoreDataのコンテキスト構成
コンテキスト以下の構成図を貼ってみます。
ColumnもといEntityを追加したい場合にはNSManagedObjectModelへの操作、接続するDBを増やしたい場合にはNSPersistentStoreを追加するといった形です。
NSPersistantStore追加の際の実DBファイル
接続するDBを増やす場合にはNSPersistentStoreを追加するわけですが、実体のファイルもその際に自動で生成されています。
データ追加
NSEntityDescriptionで追加先のEntityを指定すると生成されるオブジェクト（レコード相当)に値を入れて保存、という流れです。DBへのレコード追加をSQLを直接触れずに行う形です。
データの読み込み
NSFetchedResultsControllerを生成した時点で、データの取得ができ上がるため、あとは取得したデータの配列からインデックスを指定して取得という流れ。
まとめ
NSManagedObjectContextを構成する際の煩雑さも原因だと思うので、NSManagedObjectContextまでの生成過程を一つのクラスにして分離したほうが、なにかと分かりやすいかと思います。
あと、これらを一つ一つ確かめていくとどこかで同じ構成をみたような感覚があったのですが、PerlにおけるDBIx::Classがそれでした。どんな感じなのかは、
を読むと分かりやすいと思います。