Core Data Fundamentals of iOS Development

今､ 私たちはたくさんの新しい言葉に出会いましたが､ 実はどれも私たちがよく知っている概念と同じことを表しているのです｡ 例えば､ オブジェクト指向プログラミングの世界ではクラスと呼ばれるものがありますが､ Core Dataの世界ではそれがエンティティと呼ばれるものです｡ そして､ データベースといえば､ それは単純にデータを表すテーブルに過ぎません｡ そしてもうひとつ､ オブジェクト指向プログラミングでいうところのプロパティは､ 実はCore Dataでいうところの属性に近いんです｡ また､ データベースでは､ テーブルのフィールドや特定のカラムを指定するだけです｡ 例えば､ パン屋さんのテーブルを見ると､ バイヤーのテーブルは､ テーブルそのものがクラスになっています｡ そして､ Core Dataを使うのであれば､ そのテーブルはエンティティと呼ばれることになる｡ さて､ 住所､ 番号､ 請求先､ バイヤー名などの見出しを持つこれらの列は､ それぞれデータベースのフィールドです｡ また､ テーブルをクラスとして作成した場合は､ そのクラスに関連するプロパティを呼び出すことになります｡ しかし､ Core Dataでは､ それらはアトリビュートと呼ばれている｡ つまり､ ここにある1行1行がCore Dataの属性なんですね｡ つまり､ 住所は購入者のエンティティの属性となる｡ さて､ このテーブルを埋めて､ これらのプロパティをそれぞれ値にすると､ テーブル内のすべての行が新しいNSManagedObjectになります｡ Core Dataには､ 新しい用語がたくさんあるんですね｡ しかし､ エンティティについて話すとき､ クラスとテーブルについて話していることを忘れないでください｡ 属性というと､ クラスのプロパティやテーブルのカラムのことを指します｡ NSManagedObjectsの話をするときは､ 単にデータで満たされたテーブルの各行について話しているのです｡ それでは､ このモジュールの冒頭で見た3つのテーブルを拡大して見てみましょう｡ バイヤーズという存在があります｡ Product'エンティティ､ Orders'エンティティがあります｡ ここで､ 3つのエンティティまたはすべてのテーブルを永続的なストレージに格納すると､ それが永続的なコンテナになります｡ このコンテナは単純にSQLiteデータベースで､ すべてのテーブルとテーブル間のすべてのリレーションシップを保存しています｡ さて､ アプリを書くとき､ 単純に永続ストアを直接操作することはできません｡ 私たちは､ コンテクストと呼ばれる仲介者を通さなければならないのです｡ そして､ このコンテキストは､ 先ほども言ったように､ データベースに追加したい新しいデータを作成したり､ データベース内のデータに到達したり､ データベース内で更新したいものを指定したり､ データベース内で破棄したいものを指定したりする､ 一時的な領域のようなものです｡ これがCRUDと言われるものですね｡ そして､ データベースを語るとき､ この言葉をかなり多用する傾向があります｡ でも､ 単純に､ データベースでやりたいと思いがちなことをすべて意味しているんですよね｡ 作成､ 読み取り､ 更新､ 破棄｡ そして､ 重要なことは､ Core Dataでは､ これをコンテキストの中で行うということです｡ 永続的なコンテナに対して直接行うのではありません｡ この中間領域でできることは､ 変更を取り消したり､ やり直したりすることです｡ 追加と破壊､ 更新を同時に行うことができます｡ そして､ コンテキストの中で行ったことに満足できると判断したときだけ､ コンテキストの保存を行います｡ そして､ Core Dataフレームワークは､ コンテキスト内のデータの現在の状態を永続的なストアにコミットすることを引き受けます｡ 先ほども言いましたが､ これは本当にGitの例と同じようなものです｡ Gitを使う場合､ まずソースコントロールにコミットしたいものをステージング・エリアに追加する必要がありましたが､ その際にaddコマンドを使います｡ コミットしたい内容に満足したときだけ､ コミットコマンドを使用しました｡ つまり､ Core Dataでは､ 永続的なコンテナがあり､ 我々のアプリは永続的なコンテナと直接対話することができないのです｡ その代わり､ コンテクストと呼ばれる一時的な領域を通過する必要があります｡ そして､ コンテキストの内容に満足したら､ そのコンテキストの保存を行います｡ これは基本的に､ 変更を恒久的なコンテナーにコミットすることです｡ では､ コードを確認してみましょう｡ 今まではCRUDのC､ つまりcreateの中のcreate-read-update-destroyしか実装していませんでした｡ しかし､ そのためには､ 実は､ 先ほどお話したcontextやpersistentContainerなど､ すべてのものに出くわす必要がありました｡ まず､ contextという定数を作成し､ これがAppDelegateに入り､ persistentContainerを取得する｡ そして､ そのpersistentContainerのコンテキストへの参照を取得します｡ AppDelegateの内部を見ると､ 遅延ロードされたpersistentContainerがあり､ 実際に取得したり使おうとしたときにだけロードされるようになっています｡ これは基本的に NSPersistentContainer タイプの新しいコンテナで､ ここにある DataModel 内で指定した構造を使って作成されます｡ この構造には Item というエンティティが 1 つあり､ Item には done と title という 2 つの属性があります｡ そして､ PersistentStoreをロードし､ 使用できるようにします｡ ここで､ Persistent Storesのコンテキストにアクセスします｡ これは一時的な領域で､ アプリはこの領域にアクセスすることになることを覚えておいてください｡ 次に､ テーブルビューに新しい項目を追加する場合､ Item 型の新しいオブジェクトを作成します｡ そして､ このクラスは DataModel 内でその名前を持つ新しいエンティティを作成するときに自動的に生成されることを覚えておいてください｡ そしてそのクラスは､ 属性として指定したすべてのプロパティ（titleとdone）にすでにアクセスできるようになっています｡ そこで､ newItemを作成し､ そのアイテムはNSManagedObject型のオブジェクトであることを確認します｡ 先ほど､ NSManagedObjectは基本的にテーブルの中にある行であると言いましたが､ それを思い出してください｡ そして､ すべての行が個々のNSManagedObjectになります｡ そして､ そのフィールドをすべて埋めるのです｡ つまり､ タイトルフィールドと完了フィールドです｡ そして､ それが済んだら､ アイテムを保存するのです｡ saveItemの関数の中には､ エラーを投げる可能性のあるメソッドがあります｡ そのため､ tryが付けられており､ 何か問題があればエラーをキャッチするようにしています｡ しかし､ ここで行うのは､ コンテキスト､ つまり､ ここで編集した一時的な領域を調べ､ そのコンテキストの中に新しいNSManagedObjectを作成することである｡ そして､ 保存されていない変更をPersistentStoreにコミットできるように､ コンテキストを保存します｡ このレッスンでは新しい単語や新しい概念がたくさん出てきますので､ このレッスンを何度か見て､ コア・データ・モジュールを見終わってから､ これらの概念のいくつかを自分で復習してみるのもいいかもしれませんね｡ ですから､ この段階になると､ より多くの新しいコンセプトが登場し､ 学習曲線が加速していくことでしょう｡ そのため､ ここに書かれている多くの知識を本当に理解するためには､ 時間をかけて染み込ませたり､ 繰り返し練習したりする必要があると感じるかもしれません｡ 次のレッスンでは､ CRUDのR､ つまり永続的なコンテナからアイテムを読み取ることにどのように対処するかを見ていきます｡ そんなこんなで､ 次回のレッスンでお会いしましょう｡