私は Applicasa の開発者エバンジェリストです。モバイル アプリ開発者向けの優れたツール セットを作成しました。その一部には、Parse や StackMob などとは少し異なるアプローチを取る BaaS サービスの提供が含まれます。バックエンドを他のプロバイダーまたは独自のプロバイダーに置き換えることができるように、サードパーティの SDK API から抽象化するという問題に取り組むための役立つ視点を提供すると思います。/免責事項
このようなものはありますか？私はすでに成功せずに検索しましたが、間違った方向を見ているのかもしれません
類似した差別化された機能を提供する BaaS プロバイダーは他にもありますが、サードパーティ プロバイダーを不可知論的な方法で完全に抽象化する製品を私は知りません。
このようなもののベストプラクティスは何ですか?
あなたはすでに、正しい方向に向けてしっかりとした足場を築いていることを示していると思います。
まず、バックエンドにとらわれない方法でオブジェクトと必要な機能をカプセル化するさまざまなクラスが多数作成されるという予測は正しいです。もちろん、その数は、どのような抽象化とカプセル化を追求するかによって異なります。あなたが概説したアプローチは、私がそのようなプロジェクトを開始する方法のようにも聞こえます.アプリケーションが対話する必要があるすべてのオブジェクトのクラスを作成し、それらのクラス（またはそれらがすべて拡張する基本クラス）にカスタムメソッドを実装します.これにより、バックエンド プロバイダーとやり取りする実際の作業が行われます。
したがって、たとえば 、 、および オブジェクトを持つアプリを構築する場合、FooこれらBarのBazクラスを内部 API の一部として作成し、アプリに必要なすべての機能を備えます。すべてのアプリ ロジックと機能操作はそれらのクラスとのみ対話し、すべてのアプリ ロジックと機能はデータ バックエンドに依存しません (つまり、内部機能はデータ バックエンドに依存できませんが、オブジェクト クラスは、操作を許可する一貫したインターフェイスを提供します)。データ処理メソッドを非公開に保ちながら実行されます)。
次に、各クラスがクラスから継承されるようBaseObjectにします。これには、実際にデータ バックエンド (プロバイダー ベースまたは独自のカスタム リモート バックエンド) と通信するメソッドが含まれます。BaseObjectクラスには、、、などのメソッドが含まれるsaveObject場合があります (オブジェクトのフィルタリング/検索を実行するための適切なパラメーターがいくつかあります)。そうすれば、将来バックエンド データ サービスを置き換えたいときに、データのやり取りを処理するクラス メソッドの更新に集中するだけで済み、アプリのすべてのロジックと機能は、、およびクラスに関連付けられており、実際には、取得/保存/更新/削除操作が舞台裏でどのように機能するかは気にしません。getById:getObjectsBaseObjectFooBarBaz
ここで、物事をできるだけ簡単にするために、BaaS スキーマを内部オブジェクト クラス名と一致するように構築します (ここでは、BaaS の要件に応じて、isKindOfClass:またはNSStringFromClass:呼び出しを使用できます)。これは、Parse を使用している場合、データ アクションを実行するクラス名をsave取得するメソッドを作成する必要があることを意味します。NSStringFromClass:データ操作用のネイティブ オブジェクトのカスタム SDK を生成する Applicasa のようなサービスを使用していた場合、結果に基づいてカスタム データ アクションを実行したいと思いisKindOfClass:ます。それよりもさらに柔軟性が必要な場合 (おそらく、複数のバックエンド プロバイダーを使用できるようにするため、またはその他の複雑な要件)、すべての子クラスにBaseObject、何らかのカスタム メソッドを介してデータ操作に使用するスキーマ名を正確に伝えるようにします。 、 お気に入りgetSchemaName. おそらくBaseObject、デフォルトでクラス名を文字列として返すメソッドとして定義しますが、子クラスに実装してさらにカスタマイズします。したがって、BaseObject saveメソッドの内部は次のようになります。
- (BOOL) save {
// call backend-specific method for saving an object
BaasProviderObject *objectToSave = [BaasProviderObject
objectWithClassName:[self getSchemaName]];
// Transfer all object properties to BaasProviderObject properties
// Implement however it makes the most sense for BaasProvider
// After you've set all calling object properties to BaasProviderObject
// key-value pairs or object properties, you call the BaasProvider's save
[objectToSave save];
// Return a BOOL value to indicate actual success/failure
return YES; // you'll want this to come from BaaS
}
次に、たとえばFooクラスで、次のgetSchemaNameように実装します。
- (NSString) getSchemaName {
// Return a custom NSString for BaasProvider schema
return @"dbFoo";
}
それが理にかなっていることを願っています。
Parse SDK を使用しているコードが適切に識別され、含まれていることを確認するだけで、Parse SDK に固執する必要がありますか?
このような内部抽象化は、事前にかなりの量の作業が必要になりますが、必然的に、必要に応じて実装するための多くの柔軟性が提供されます。CoreData を実装し、CoreData を拒否し、本当にやりたいことは何でもできます。内部アプリのロジック/機能をデータに依存しない方法で構築することには、明確な利点があります。たとえば、アプリ コードのカスタム ブランチで別の BaaS を簡単に試して、別のプロバイダーがどのように気に入っているかを確認できるようにするためでも (または、独自のデータ ソリューションを開発するための簡単な方法を提供します)。
それが役立つことを願っています。