Androidアプリのリレーショナルデータベースに直接アクセスする代わりにWebサービスを使用する理由

リモートロケーションの中央データベースに効率的な方法でアクセスする方法をWebで検索し、データベースへの直接アクセス（JDBCなど）の代わりにWebサービスを使用するよう提案しました。 。

Webサービスレイヤーを追加すると、必要なCPUパワーと処理中に使用される帯域幅の両方の点で、クライアントをより軽量にする機会が与えられます。両方の要素はエンドユーザーにとって非常に重要です：

• より少ないCPUを使用すると、バッテリーの寿命が長くなり、
• より少ない帯域幅を使用すると、従量制プランのユーザーに対する毎月の支払いが削減されます

Webアプリケーションレイヤーを導入することにより、処理の大部分を、ハンドヘルドモバイルの低電力、低帯域幅、低メモリのクライアントから、それよりも多くのメモリを持つプラグイン、高電力、高帯域幅のサーバーに移動します。ニーズ-処理と通信にかかる費用がクライアントにかかる費用の数分の1である環境。

しかし、ちょっと待ってください。システムを分割することで、ビジネスルール、データベースの構造、およびそこにあるもののバージョンをさらに制御できるようになります。モバイルクライアントをデータベースに直接接続すると、デザインはそのデータベース構造と「結婚」します。ほとんどすべての変更は、クライアントの下位互換性を破壊し、アプリのアップグレードをためらう可能性があります。

対照的に、間にWebサービスを追加すると、モバイルクライアントへのインターフェイスをより管理しやすい方法で進化させることができます。たとえば、古いインターフェイスを所定の位置に保ち、それと「並列」に動作する新しいインターフェイスを追加してから、完全に単一のクライアントを壊さずにデータベースを再構築します。

Webサービスの設計中にいくつかの非常に基本的な設計原則に従うと、適切に配置された成熟したサーバー側インフラストラクチャを再利用することで大きなメリットを得ることができます。たとえば、キャッシュサービスとプロキシサービスを無料で取得できます。

最後に、これにより、自分でサービスを提供できなかったプラットフォームにアプリケーションを公開し、最終的に会社の利益につながる他の開発者への扉が開かれます。

アプリとDBの間に抽象化レイヤーを配置します。これにより、次のような多くの利点が得られます。

• DBへのアクセスを、アプリが必要とする部分のみに制限します。これにより、アプリのコードが簡素化され、DBのセキュリティが確保されます。
• DBの内部動作を抽象化するため、後でスキーマ、クエリ、またはデータベース全体を変更することにした場合でも、中間層を正しく維持する限り、アプリへのリンクは壊れません。
• DBの範囲外の機能を追加できます。たとえば、ほぼ一定のデータをキャッシュします。ビジネス・ルールは、別の一部である必要があります離れてDBからなります。

DBを直接公開しないもう1つの理由-トランスポート。JDBCと対話する種類のほとんどのリレーショナルデータベースは、一般にパブリックインターネット用に設計されていません。ワイヤレスインターネットは、このパブリックインターネットの恐ろしく信頼性の低い目的です。例外処理は悪夢であり、おそらくトランザクションの損失を避けるために、アプリ内でWebサービスレイヤーの逆を書くことになります。

HTTPを使用する新しい種類のデータベースがいくつかあり、この種のデータベースに適している場合があります。また、データベースにある種のアプリケーションコードを配置する方法を特徴とする傾向があります。CouchDbまたはRavenDbに注目してください。どちらも、多くの最新のWebサービスと同様に、jsonおよびhttpで機能するmap / reduce機能を備えたドキュメントデータベースです。