データベースに直接接続するのではなく、Webサービスを介してリモートデータベースに接続する必要がある理由の「トップ10」リストを探しています。これは現在内部での議論であり、私はプロWebサービスですが、議論を失っています。私はWCF / Webサービスの基本を理解していますが、他の誰も理解していません。前進したいことは何でもできますが、現在選択していることに固執する必要があります。
これが私が思いついたものです。もう？
回答:
セキュリティ。Webサーバー/アプリユーザー以外にDBアクセスを許可していません。
これは、大量のユーザーがいる場合に特に重要です。DB側でのユーザー/ロールメンテナンスの痛みを回避できます。
DB負荷の軽減。Webサービスは、DBから取得したデータをキャッシュできます。
データベース接続プール（hat / tip @Dogs）。
Webサービスは、永続的に開かれたDB接続の小さなプールを使用できます。はさまざまな方法で役立ちます。
データベース接続プールは、データベースサーバー側で制限されています。
新しいDB接続を開くと、（特にデータベースサーバーにとって）非常にコストがかかります。
フォールトトレランス機能-サービスは、サービスの利用者がフェイルオーバーの詳細を実装しなくても、プライマリ/ DRデータソースを切り替えることができます。
スケーラビリティ-サービスは、サービスコンシューマがリソース選択の詳細を実装しなくても、複数の並列データソース間でリクエストを分散できます。
カプセル化。サービスユーザーに影響を与えることなく、基盤となるDB実装を変更できます。
データ強化（これには、クライアントのカスタマイズからローカリゼーションから内部化までが含まれます）。基本的にこれらはどれも便利かもしれませんが、どれもデータベースへの大きな負荷であり、DB内に実装するのが非常に難しいことがよくあります。
あなたに当てはまる場合と当てはまらない場合があります-特定のアーキテクチャの決定は、DBアクセスに適していません。たとえば、Unixで実行されているJavaサーバーはデータベースに簡単にアクセスできますが、Windows PCで実行されているJavaクライアントはデータベースに対応していないため、データベースにしたくありません。
移植性。すべてのクライアントが同じプラットフォーム/アーキテクチャ/言語を使用しているとは限りません。それらのそれぞれで適切なデータアクセスレイヤーを再作成することは、Webサービスのコンシューマーレイヤーを構築するよりも（前述のフェイルオーバーなどの問題を考慮に入れる必要があるため）困難です。
性能調整。クライアントが独自のクエリを実行している（事前に用意されたストアドプロシージャではない）場合は、100％確実に、最適でないクエリを使用するようになります。また、Webサービスが許容されるクエリのセットを制限している場合は、データベースのチューニングに大きく役立ちます。このロジックは、ストアドプロシージャにも同様に適用でき、Webサービスに固有のものではないことを付け加えておきます。
このページにも適切なリストがあります。「データベースアクセスのカプセル化：アジャイルな「ベストプラクティス」」
ただ明確にするために-これらの問題の一部は、すべての状況に適用できるとは限りません。一部の人々は、移植性を気にしません。DBセキュリティについて心配する必要がない人もいます。一部の人々は、DBのスケーラビリティについて心配する必要はありません。
私の意見では、データベースをWebサービスとして自動的に公開するべきではありません。データを公開するためのサービスが必要であることが判明した場合は、サービスを記述しますが、すべてのデータベースアクセスをWebサービス経由で行う必要はありません。
これらのポイントのほとんどは、特にWebサービスではなく、任意の正式なAPIに当てはまります。
ストアドプロシージャへの呼び出しを単純にラップするWebサービスを作成することは、優れたDALを設計するための誤ったアプローチのようです。おそらく、ストアドプロシージャは、古いクライアントサーバーシステムから残されたレガシーコードです。つまり、ビジネスルールはSPに埋め込まれています。その場合は、雌豚の耳から絹の財布を作成しようとしています。
さらに、SOAPメッセージプロトコルレイヤーを追加すると、この「豚」と付き合うように「強制」されたWebアプリにパフォーマンスヒットが追加されます。私は現在、新しいMVC-4アプリがそのようなDALを使用するように指示されているプロジェクトに取り組んでいます。このような変更を必要とする新しいユーザーストーリーが発生した場合は常に、WebMethodシグネチャとSPシグネチャの両方を変更する必要があります。私たちにとって、これはすべてのスプリントです。このようなパススルーアプローチの本質は、2つの密結合層です。
一般に
私はASP.NET Web Apiをじっと見つめ始めており、最初にデータサービスを作成することを計画しています。
私は最近、エンティティフレームワークを使用した.NET MVC Webアプリケーションに焦点を当てています。
私は最近、もともとOracleのストアドプロシージャに基づいて構築していたMVC Webアプリの不満に悩まされていました。Oracle 9またはそれ以前の元のバージョンでは、Visual Studio 2012に別の問題があり、Web構成接続とTNS名に基づいて使用する適切なdllファイルをロード時間アセンブリで検索するという、より新しい接続ファクトリアプローチが採用されていました。
データベースへの接続試行は、「サポートされなくなりました」というエラーメッセージが表示されて失敗しました。好奇心から、Oracle 12cをダウンロードして、TNS名とロードアセンブリdllでうまく機能するアプリケーションレベルの接続をいくつか作成しましたが、Oracleで問題なく作業できました。
古いバージョンのOracleへの接続で機能するWebサービスがいくつか構築されていました。それらは、選択されたテーブルに明確にマップされたメソッドを使用して作成されましたが、残念です。自分で書く必要があります。
Oracleデータベースの保守を担当するグループは、クライアントインターフェースとビジネスロジックレイヤーを抽象化するために使用していた古いストアドプロシージャを置き換える新しいストアドプロシージャを作成することになると言われました。
したがって、私が最初に考えたのは、ドロップダウンリストへの入力や企業全体のデータでのオートコンプリートなどの一般的なデータリクエストはすべて、Oracleストアドプロシージャを呼び出すデータサービスを通じて行われるということでした。アプリケーションごとにそのプロセスを繰り返し、各開発者が構成とバージョン/ロードアセンブリ、TNSの問題に苦労するのはなぜですか？
そう....
私はDBAではなくアプリケーション開発者/アナリストなので、私の見方は、データベースツールが進化するときにアプリケーションを絶えず変更しなければならないという終わりのないフラストレーションの経験からのものです。