2

というビューがありますCart。s の表を表示しますItem。これらItemは永続化する必要があるため、ItemNSManagedObject をサブクラス化します。id、 などの値は、アクセサーが自動的に生成されるpriceプロパティです。@dynamic

という別のビューがありFavoritesます。のテーブルが表示されますが、Item永続化する必要はありません。実際、このビューは、ユーザーが異なる資格情報でログインするたびに変化します。

2 つのビューの関係は、ユーザーが自分のお気に入りから自分のカートにアイテムを追加できることです。Itemカートには、さまざまなリストのを格納できFavoritesます。Favoritesアイテムがカートに追加されても、リストは変更されません。

最初に、Favoritesビューのモデルを NSDictionary オブジェクトの NSArray にしました。ユーザーがアイテムをカートに追加すると、NSDictionary のキーと値のペアから Core Data にアイテムを作成して保存します。このアプローチは、あまりクリーンでもドライでもないように見えます。Favoritesビューのモデルを s の NSArray にする方が理にかなっているのではないでしょうItemか?

したがって、私の意図はItem、Core Data モデル (NSManagedObject) を表すだけでなく、ビューでも動作するようにクラスを実装するFavoritesことです。Objective-C と iOS の開発は初めてなので、これがどのように機能するか、どのように見えるかは本当にわかりません。私のために魔法のように作成されたアクセサーをオーバーライドする必要があるようですが、呼び出しを使用してコンパイル時にそれらを呼び出すことはできませんsuper...誰でもNSDictionaryデータを返すことを知っているときの大まかな概要を教えてもらえますか?またはコアデータデータ？Core Data データの場合、魔法のように生成されたアクセサーと同じレベルの効率を維持するにはどうすればよいでしょうか?

さらに良いことに、DRY と同じか、より理にかなったより良い実装はありますか? それとも、あまりにも多くの機能を 1 つのクラスにまとめようとしていますか? この場合、NSDictionary オブジェクトの NSArray が最善の方法ですか?

4

1 に答える 1

1

フェッチ要求で結果のタイプ (オブジェクト、オブジェクト ID、カウント、辞書) を指定できます。

また、MOC の外では NSManagedObjects を使用しません。メモリのものに使用する別のオブジェクトを用意するか、それらのオブジェクトにメモリ内永続ストアを使用できます...または、使用するメイン データベース MOC の子として別の MOC を作成するだけです。メモリ内オブジェクト用。

これらのアプローチの利点は、コードがディスクにバックアップされているかどうかをコードで知る必要がないことです。

MOC を保存しない限り、これらのオブジェクトへの変更がディスクに保存されることはありません。

編集

NSFetchRequest *fetchRequest = // create the fetch request...
fetchRequest.resultType = NSDictionaryResultType;

ここで、フェッチを行うと、NSManagedObject の配列を取得する代わりに、NSDictionary の配列を取得します。

于 2012-05-10T05:36:05.080 に答える