Androidアプリのリレーショナルデータベースに直接アクセスする代わりに、なぜWebサービスを使用するのですか？
離れた場所にある中央データベースに効率的にアクセスする方法をウェブで検索したところ、データベースへの直接アクセス（JDBCなど）の代わりにウェブサービスを使用するという提案がありました。 。
Webサービスレイヤーを追加すると、必要なCPUパワーと処理中に使用される帯域幅の両方に関して、クライアントをより軽量にする機会が得られます。どちらの要素もエンドユーザーにとって非常に重要です。
- より少ないCPUを使用すると、バッテリーの寿命が長くなります。
- より少ない帯域幅を使用すると、従量制プランのユーザーの毎月の支払いが減少します
Webアプリケーション層を導入することで、処理の大部分をハンドヘルドモバイルの低電力、低帯域幅、低メモリのクライアントから、それよりも多くのメモリを持つプラグインされた高電力、高帯域幅のサーバーに移動します。ニーズ-処理と通信のコストがクライアントでのコストのほんの一部である環境。
しかし、ちょっと待ってください。システムを分割することで、ビジネスルール、データベースの構造、および存在するバージョンのバージョンをより詳細に制御できます。モバイルクライアントをデータベースに直接接続させると、設計はそのデータベース構造と「結合」されます。ほとんどの変更は、アプリのアップグレードに消極的なクライアントとの下位互換性を損なうことになります。
対照的に、間にWebサービスを追加すると、より管理しやすい方法でモバイルクライアントへのインターフェイスを進化させることができます。たとえば、古いインターフェイスをそのままにして、それと「並行して」動作する新しいインターフェイスを追加して、完全に単一のクライアントを壊すことなくデータベースを再構築します。
Webサービスを設計する際にかなり基本的な設計原則に従うと、導入済みの成熟したサーバー側インフラストラクチャを再利用することで、大きなメリットを得ることができます。たとえば、キャッシュサービスとプロキシサービスを無料で利用できます。
最後に、これは他の開発者にドアを開け、自分でサービスすることができなかったプラットフォームにアプリケーションを公開し、最終的に会社の利益を発揮します。
アプリとDBの間に抽象化レイヤーを配置します。これにより、次のような多くの利点が得られます。
- DBへのアクセスをアプリが必要とする部分のみに制限する。これにより、アプリのコードが簡素化され、DBが安全に保たれます。
- DBの内部動作を抽象化するため、後でスキーマ、クエリ、またはデータベース全体を変更する場合でも、中間層を正しく維持している限り、アプリへのリンクは壊れません。
- これにより、DBの範囲外の機能を追加できます。たとえば、かなり一定のデータをキャッシュします。ビジネスルールは、DBとは別の部分ですすべき。
DBを直接公開しないもう1つの理由-トランスポート。ほとんどのリレーショナルデータベースは、JDBCと対話するようなものであり、一般にパブリックインターネット用に設計されていません。無線インターネットは、公のインターネットのひどく信頼できない終わりです。例外処理は悪夢であり、トランザクションの損失を回避するために、アプリ内のWebサービスレイヤーの逆を書き込むことになるでしょう。
HTTPをサポートする新しい種類のデータベースがいくつかあり、この種のデータベースに適している可能性があります。彼らはまた、データベースにある種のアプリケーションコードを置く方法を特徴とする傾向があります。 CouchDbまたはRavenDbを調べてみてください。どちらも、多くの最新のWebサービスと同様に、jsonおよびhttpで機能するマップ/リデュース機能を備えたドキュメントデータベースです。