2009-10-13 15 views
169

私はコアデータを初めて使用しています。私は、コレクション型が属性型として利用できないことに気付きました。最も効率的な方法が配列/辞書型データを属性として格納することを知りたいと思っています(例えば、通りや都市などのアドレスを構成する要素別のエンティティを必要とせず、別個の属性/フィールドよりも辞書/配列としてより便利に格納される)。ありがとうございました。ベストプラクティス? - コアデータエンティティ属性としての配列/ディクショナリ

+5

は – Daniel

答えて

238

コアデータに「ネイティブ」配列または辞書型はありません。変形可能な属性としてNSArrayまたはNSDictionaryを格納できます。これはNSCodingを使用して配列または辞書をNSData属性にシリアル化します(アクセス時に適切に逆シリアル化します)。このアプローチの利点は簡単だということです。欠点は、配列や辞書(データストア内のBLOBとして格納されている)にクエリを実行できないことと、コレクションが大きい場合は、データストアから/にデータを移動する必要があることですSQLiteデータストア)を使用して、コレクションの小さな部分を読み取ったり変更したりすることができます。

代わりに、Core Data-Manyリレーションシップを使用して、配列または辞書コレクションのセマンティクスをモデル化することもできます。配列が簡単なので、それを使い始めることができます。コアデータの多対多関係は実際にはセットをモデル化しているので、配列のような機能が必要な場合は、セットをソートするか(フェッチされたプロパティを使用してこれを行うのが便利です)、エンティティに追加のインデックス属性を追加するか配列アイテムを格納し、インデックスを自分で管理します。同種の配列を格納する場合(すべてのエントリが同じ型)、配列エンティティのエンティティ記述をモデル化するのは簡単です。そうでない場合は、変換可能な属性を使用してアイテムデータを格納するか、アイテムエンティティのファミリを作成するかを決定する必要があります。

辞書をモデリングするには、キーと値を格納するエンティティのセットと多対多の関係が必要になります。キーと値の両方は、上で説明した配列の項目エンティティに似ています。したがって、それらはネイティブ型(事前にそれらを知っている場合)、変形可能な属性、または型固有のエンティティのファミリからのインスタンスへの関係のいずれかになります。

このすべてが少し難しいと思われる場合は、それがあります。コアデータのようなスキーマ依存フレームワークに任意のデータを集約するのは難しいです。

アドレスのような構造化データの場合、エンティティを明示的にモデル化する時間(アドレスの各部分の属性など)はほとんどいつもより簡単です。辞書をモデル化するための余分なコードをすべて避けるだけでなく、これにより、UIがより簡単になります(バインディングは「うまくいくでしょう」)。 OS X 10.7のよう

更新

、Core Dataは、配列の代わりに使用することができる順序付けられたセットのタイプを含みます。 10.7以降をターゲットにできるのなら、これは順序付けされた(配列のような)コレクションにとって最適なソリューションです。

+0

が出向...おそらくあなたがあなたの鍵を覚えている辞書よりも使いやすくなって - 私はすでに考えたものを確認したが、私は変換可能な属性については知りませんでした。 – jkp

+0

@バリー私は好奇心が強いです、いつ変換可能な "正しい"時間を使うのでしょうか?エンティティに文字列が配列されていて、配列に100個以上のアイテムが含まれていないとし、文字列が平均英語の単語であれば、transformableを使用できますか? – pixelfreak

+3

@pixelfreakトランスフォームの使用は、コレクション内のアイテムをどのように使用する必要があるかによって異なります。それらに対して照会する必要がある場合、またはそれらの一部またはすべてを遅延ロードできるようにする場合は、変換可能な属性は機能しません。遅延ロードを必要としない場合は、クエリを実行する必要はなく、アイテムのすべて*が必要な場合もありません。変形可能な属性が機能する場合もあります(実装が容易な場合もあります)。 –

11

私も同様の問題がありました。私の場合は、文字列の配列をマップしたいと思っていました。私はBarryの助言に従って、ついにそれを働かせました。ここにいくつかのコードがどのように見えるかがあります(これは、これに繋がる他の誰かのことをうまく明確にします)...

私のエンティティは、このようなものになります

@interface AppointmentSearchResponse : NSManagedObject 
@property (nonatomic, retain) NSSet *messages; 
@end 

は、オブジェクトモデルコード(コアデータ)コードを管理するマイはこのようなものになります。

NSEntityDescription *entityDescription = [[NSEntityDescription alloc] init]; 
[entityDescription setName:@"AppointmentSearchResponse"]; 
[entityDescription setManagedObjectClassName:@"AppointmentSearchResponse"]; 

NSMutableArray *appointmentSearchResponseProperties = [NSMutableArray array]; 
NSAttributeDescription *messageType = [[NSAttributeDescription alloc] init];  
[messageType setName:@"messages"]; 
[messageType setAttributeType:NSTransformableAttributeType]; 
[appointmentSearchResponseProperties addObject:messageType]; 

[entityDescription setProperties:appointmentSearchResponseProperties]; 

をので、ここで重要な項目は以下のとおりです。

  • プロパティタイプにNSSetを使用しています
  • 私は、Core Data Managed Object Modelの属性タイプとしてNSTransformableAttributeTypeを使用しています。アドレスの文字列フィールドを持つエンティティを作る
+0

initメソッド内でこのコードをAppointmentSearchResponse.mの中に入れていますか? – Chicowitz

関連する問題