11

アプリでParse(parse.com)を使用したい。解析はPFObjectモデルを使用します。コード全体で独自のモデルを使用したい(解析に依存しないようにするため)。可能であれば、必要に応じて解析を別のクラウドサービスにできるだけシームレスに置き換えることができるように、アプリを設計したいと思います。

これは良い考えですか?アプリに解析コードの痕跡がない(または最小限の)ようにモデルストレージを抽象化するための最良の方法は何ですか?

おそらく、アダプターデザインパターンを使用して、解析オブジェクトを自分のオブジェクトにマップしますか?これは独立したクラスである必要がありますか、それともモデルロジックの一部である必要がありますか?

誰かがこのようなことを試みたなら、私はあなたの考えを聞きたいです。コードで直接解析モデルを使用する必要がありますか?または、解析オブジェクトに基づいてモデルを生成するシングルトンファクトリですか?

ヒント/考え/コメントはありますか?

4

2 に答える 2

3

私はこれを管理するための比較的クリーンな方法を見つけました。

NPDictionaryRepresenting基本的に、どのクラスが辞書に変換されるか、または辞書から初期化されるかを指定するために、どのクラスが準拠できるかというプロトコルを作成しました。

@protocol NPDictionaryRepresenting <NSObject>
- (NSDictionary *)dictionaryRepresentation;
+ (id)objectWithDictionaryRepresentation:(NSDictionary *)dictionary;
@end 

Parseに保存する必要のある各モデルはこれに準拠し、独自のカスタム動作を実装します。このプロトコルは辞書を使用して抽象化されているため、Parseに依存することはありません。

次に、すべてのネットワークストレージを処理するためにNPNetworkAdapter基本クラスを実装しました。また、NPNetworkAdapterから継承するNPParseNetworkAdapterクラスも実装しました。これは、Parseについて何でも知っている唯一のクラスです。そのインターフェイスは、NPDictionaryRepresentingに準拠するオブジェクトを処理します。解析ネットワークアダプタは、オブジェクトのディクショナリ表現を抽出することでPFObjectを作成できます。逆に、PFObjectをフェッチし、辞書を使用してそれらをインスタンス化することにより、自分のモデルを返すことができます。

この実装の欠点は、オブジェクトの関係ではうまく機能しないことです(ただし、私はそれに取り組んでいます)。

このアプローチについて誰かコメントがあれば、ぜひ聞いてみてください。

于 2013-01-17T20:09:00.213 に答える
3

これは古い質問だと思いますが、まったく同じ問題を引き起こすプロジェクトに忙しく取り組んでいるので、コメントしたいと思いました。まず、これを特定し、コードをParseと緊密に結合しないようにすることはうまくいったと思います。

私が採用することにしたルートはProtocols、モデルクラスに(インターフェイス)を使用することです。基礎となる実装はParseオブジェクトであり、Parseサブクラス化機能を使用します。これをファクトリクラスの使用と組み合わせて、オブジェクトの作成と実装の詳細をほとんどのアプリケーションコードから切り離しました。これはやり過ぎのように思えるかもしれませんし、事前に少し余分なコードが必要ですが、テストと、バックエンドサービスへのアクセス方法を変更するときが来たら、それは利益をもたらすと思います。

私にとってのもう1つの選択肢は、PFObjectをラップしたばかりのラッパークラスを利用することでした。ただし、私の場合、ラッパークラスはProtocols、テストを提供する追加の利点がなければ、ダムの委任クラスであったため、このProtocolsアプローチに固執しました。

于 2013-09-15T19:14:21.103 に答える