Open tomoyasuzuki opened 5 years ago
記述されているのは container と context . containerはデータを保存する場所で、contextはcontainerの中のデータを一時的に保存するエリア。 ViewController内でcontexを扱う必要がある(これは毎回?) その際にAppDelegateクラスをオブジェクトとして扱う必要がある。その時にの書き方が
let context = (UIApplication.shared.delegate as! AppDelegate).persistentContainer.viewContext
みたいな感じだった。 とりあえずこのcontextからデータの取得や保存を行うみたい。 context.save()すればCoreData内にデータを保存することができる。
まず大前提としてCoreDataに保存したオブジェクトをインスタンス化(メモリ上に展開)する時には内部でテーブルをオブジェクトに変換してくれている。インスタンス化する時にcontextを指定する必要があるみたいだけど、これは毎回必要なのだろうか。そうだとしたらシングルトンに毎回暗黙の依存をしてしまうのであんまり良くない気がする。。。 後はnilを許容しないプロパティを持つクラスを普通にインスタンス化する場合はイニシャライズする時に値が入ることを保証できるが、CoreDataのオブジェクト(つまりNSManagedObject)としてインスタンス化するとそれが保証できないのは怖くないだろうか?
ObjectOriented | CoreData | Database |
---|---|---|
Class | Entity | Table |
Property | Attribute | Field |
普通にCoreDataにテーブルを作成するとそのテーブルをオブジェクトにマッピングしたNSManagedObject型のクラスが作成されるのでそれをインスタンス化させるだけで生成はOK。
生成しただけじゃフィールドの中身が何もない状態だから、attribute(= property)の値を設定する必要がある。生成するたびに別のフィールドが作成されるのでちょっとオブジェクトとは扱いが違うかも。生成したら cotext.save()
しないと保存されない。
読み取りは fetchなんたらを使用する。これも基本的には cotext.save()
するときと似ている。
ただテーブル結合みたいな機能があるのかはわからないので、今はEntityを指定してテーブル全てのフィールドを読み取っている。
cotext.save()
するだけ
基本は cotext.delete(object:NSManagedObject)
でオブジェクトを指定して削除するだけ。
ただしテーブルは基本的に順序が存在しないので、インデックスで指定して削除することはできない。だからCoreDataを使用するときは一度データを配列に格納するような処理を毎回してあげなくちゃいけないような気もする。あとsaveは毎回必要。これはもうエラー処理も含めたメソッドとしてどこでも使えるようにしておいた方が良いかも。そーゆー意味でもやっぱり毎回AppDelegateに依存したくないので、DataBaseControllerみたいな特定のクラスを作成しておくのが無難そう。
Config
Entityとattributesで構成される。EntityはClassに近い概念で、attributesはPropertyに近い概念。Entityはテーブルであり、attributesを指定する際には型を指定する必要がある。Optionalと 非Optionaを指定できるので、必須なのかそうではないのかで使い分ける。
CoreDataに存在するEntityは普通のクラスと同じように使用でき、またattributesはプロパティと同じように使用できる。これはビルド時にXcodeがCoreDataのデータモデルに合わせてクラスファイルを作成しているからだ。これにはいくつか方法があって、1つ目はClassDefinition。他にも2つあるが、基本的には使用しない。カスタマイズしたメソッドなどを使用したいときはClassDefinitionの1つ下の奴を使う。