2

アプリケーションがサーバー（通常はJSON文字列）からデータをプルするのは、かなり一般的なシナリオです。次に、このデータが解析され、NSString、NSArray、NSDictionaryなどのネイティブクラスに変換されます。

ただし、ほとんどの場合、このリモートデータを表すためにカスタムモデルを使用する必要があります。

たとえば、ブログ投稿のJSON配列を取得する場合、それらをBlogPostモデルオブジェクトにマップします。たとえば、次のようになります。

// BlogPost.h
@interface BlogPost: NSObject
@property NSString *title;
@property NSString *body;
@property NSDate *dateCreated;
@property NSArray *comments;
@end

「JSON」モデルをネイティブモデルから切り離すためのアプローチは何ですか？

私はしばしば、辞書（通常はJSONフィードから取得）を取得するカスタム初期化子をモデル自体に記述していることに気付きます。

例えば：

// BlogPost.h
+ (BlogPost *)blogPostWithJSON:(NSDictionary *)jsonDictionary;

次に、サーバーで使用されているキーを追跡し、それらを自分のプロパティにマップする必要があります。

アプリケーションのモデルは、サーバーで使用されているキーを実際に知る必要がないため、これを行うのは常に少し不安です。

代わりに、このJSONからオブジェクトへのマッピングを別のクラスに移動する必要がありますか？おそらく工場？または、ネットワークマネージャーが既製のオブジェクトを作成して直接私に返す必要がありますか？

おそらく次のようなものです：

// NetworkManager.h
- (void)getBlogPostWithCompletion:(void (^)(BlogPost *blogPost))completionBlock;

（もちろん、どのブログ投稿を取得するかなど、ここでは多くの詳細を省略していますが、それはアプローチを示すためだけのものです）。

他のアプローチはありますか？サーバーデータをローカルモデルからどのように切り離しますか？

4

1 に答える 1

1

私はこの問題に数回直面し、あなたとほとんど同じ質問を受けました. 最後に、私がうまくいくと思うのは次のとおりです。

  • 元のモデルの OO 表現を作成します。あなたの場合、これは JSON 配列を基になるモデル (辞書?) として使用するものにデコードすることを意味します。使用しているサービスがどのようにモデル化されているかによって、いくつかの「レコード クラス」(つまり、動作のないクラス) になる場合があります。私は通常、配列や辞書の代わりにこれらのタイプのクラスを使用することを好みます。これは、ソフトウェアが進化するにつれて、必要に応じて動作を追加できるためです。一方、配列や辞書を使用する場合、それはできません。
  • 低レベルの OO モデルを作成したら、OO ドメイン モデルを作成します。この新しいモデルでは、ドメインが必要とするものを設計し、サービス プロバイダーのモデルに縛られることはありません。多くの場合、ドメイン クラスとプロバイダーのドメイン クラスの間に 1 対 1 のマッピングがありますが、これは必須ではありません。ここでのポイントは、ドメインを抽象化し、自分が正しいと思うように設計する必要があるということです。

この 2 つのモデル間のマッピングは、その複雑さに応じてさまざまな方法で行うことができます。私は通常、プロジェクトで均質なアプローチを実現するために、次の 3 つのアプローチのいずれかを選択してそれに固執することを好みます。

  1. (class)HighLevelObject>>from(aLowLevelObject)ドメイン モデルにクラス メソッドを記述します。これは低レベルのオブジェクトを取り、それ自体を構成します。これは、対応する低レベル オブジェクトを持つすべての高レベル オブジェクトに対して行います。
  2. LowLevelObject>>createHighLevelObject()前のものとは反対に、ドメイン モデルのインスタンスを作成する低レベル オブジェクトにインスタンス メソッドを記述します。ここでは、新しいオブジェクトを作成する責任を下位層に移しています。
  3. 作成プロセス全体を処理するファクトリまたはビルダー(モデルの複雑さに応じて) を作成します。

モデル間に 1 対 1 のマッピングが多数ある単純なモデルがある場合は、オプション 1 または 2 を選択します。どちらを選択するかは、好みによって大きく異なります。オプション 1) には、オブジェクトがそれ自体を構築する方法を知っているという利点がありますが、ドメイン モデルに変換プロセスの負担がかかります。2 番目のアプローチは、「よりクリーンな」ドメイン モデルを残しますが、下位層に上位層の詳細を知らしめ、カプセル化を破らざるを得なくなる可能性があります。ここに特効薬があるとは思いません。私見では、ニーズとプログラミングの好みに最も適したアプローチを選択する必要があります。

HTH

于 2013-01-14T16:29:10.027 に答える