開発者がdbへの直接接続の代わりにWebサービスを使用する必要があるのはなぜですか？
Dbに直接接続するのではなく、Webサービスを介してリモートデータベースに接続する必要がある理由の「トップ10」リストを探しています。これは現在内部討論であり、私はプロWebサービスですが、議論を失っています。私はWCF/Webサービスの基本的な理解を持っていますが、他の誰も持っていません。前進したいことは何でもできますが、今選択したものに固執する必要があります。
これが私が思いついたものです。もう？
- WCF Webサービスは、正しく構成されていれば、より安全になります。
- DBの変更は、サービスレベル（構成ファイルまたはサービスの再コンパイル）でのみ行う必要があります。
- セットアップしてホストすると、Webサービスの利用が簡単になります。
セキュリティ。 Webサーバー/アプリユーザー以外にはDBアクセスを許可していません。
これは、大量のユーザーがいる場合に特に重要です。 DB側でのユーザー/ロールのメンテナンスの痛みを回避できます。
DB負荷の削減。 Webサービスは、DBから取得したデータをキャッシュできます。
データベース接続プーリング（hat/tip @Dogs）。
Webサービスは、永続的に開かれたDB接続の小さなプールを使用できます。さまざまな方法で役立ちます：
データベースサーバー側のDB接続プールは制限されています。
新しいデータベース接続を開くには、非常にコストがかかります（特にデータベースサーバー）。
フォールトトレランスの機能-サービスは、サービスコンシューマがフェールオーバーの詳細を実装しなくても、プライマリ/ DRデータソースを切り替えることができます。
スケーラビリティ-サービスは、リソース選択の詳細をサービスコンシューマーに実装させることなく、複数の並列データソース間でリクエストを分散できます。
カプセル化。サービスユーザーに影響を与えることなく、基盤となるDBの実装を変更できます。
データの強化（これには、クライアントのカスタマイズからローカリゼーション、内部化まで何でも含まれます）。基本的にこれらのいずれかが有用かもしれませんが、それらのいずれかは、データベースへの大きな負荷であり、多くの場合、DB内に実装するのは非常に困難です。
あなたに当てはまるかもしれないし、当てはまらないかもしれません-特定のアーキテクチャの決定はDBアクセスに適していません。例えば。 Java Unixで実行されているサーバーはデータベースに簡単にアクセスできますが、Windows PCで実行されているJavaクライアントはデータベースに対応していません。
移植性。すべてのクライアントが同じプラットフォーム/アーキテクチャ/言語上にあるとは限りません。これらのそれぞれで適切なデータアクセスレイヤーを再作成することは、Webサービスのコンシューマーレイヤーを構築するよりも困難です（上記のフェールオーバーなどの問題を考慮する必要があるため）。
性能調整。クライアントが独自のクエリを実行している場合（事前に定義されたストアドプロシージャではない場合）、最適ではないクエリの使用を100％確実に開始できます。また、Webサービスが許容可能なクエリのセットを制限している場合、データベースのチューニングを大幅に支援できます。このロジックは、Webサービスに固有のものではなく、ストアドプロシージャにも同様に適用できることを付け加える必要があります。
適切なリストも見つけることができます このページ：「データベースアクセスのカプセル化：アジャイルな「ベスト」プラクティス」
明確にするために、これらの問題の一部はすべての状況に適用できない場合があります。ポータビリティを気にしない人もいます。 DBセキュリティについて心配する必要がない人もいます。 DBのスケーラビリティについて心配する必要がない人もいます。
私の意見では、データベースをWebサービスとして自動的に公開すべきではありません。データを公開するサービスが必要であることが判明した場合は、1つを記述しますが、すべてのデータベースアクセスがWebサービスを介して行われるべきではありません。
- データベース接続が安全ではない理由はありません
- データベースをデータアクセスレイヤー（おそらくEntity Framework）にカプセル化できます。
- Webサービスは、適切に作成されたデータアクセスレイヤーよりも簡単に使用できません。
- WebサービスはAPIを形成し、外部システムとアプリケーションのデータ間で許可される相互作用を定義します。
- Webサービスは、データベースを外部の相互作用から切り離し、外部の影響から独立してデータレイヤーを管理できるようにします。
- Webサービスのみによるアクセスを許可すると、アプリケーションロジックが確実に実行できるようになり、データの整合性が保護されます。
- Webサービスでは、データベースがユーザー名とパスワード/テーブルレベルの権限を必要とするのではなく、最も適切な認証/承認手段を講じることができます。
- Webサービスは、自動サービス検出と構成を使用する機会を提供します。
- Webサービスのトラフィックは、セキュリティで保護されていないネットワークを通過するために暗号化できます。それを可能にする直接のDB接続ソリューションを知りませんか...？
これらのポイントのほとんどは、特にWebサービスではなく、正式なAPIに当てはまります。
1）開発者側からのデータベース保守の頭痛が軽減され、開発にのみ集中できるようになりました。
2）Webサービスは、非常に簡単で効果的な方法で、異なるプラットフォーム（windows、ios、Androidなどのオペレーティングシステム）の通信をサポートします。たとえば、Android application＆ios applicationは、Javaベースであるため、webserviceは、 3つの異なるデータベースを維持する代わりに最適なソリューション。
ストアドプロシージャへの呼び出しを単純にラップするWebサービスを記述することは、適切なDALを設計するための誤ったアプローチのようです。おそらく、ストアドプロシージャは、古いクライアントサーバーシステムから残されたレガシーコードです。つまり、ビジネスルールはSPに埋もれています。その場合、あなたは本当に雌豚の耳から絹の財布を作成しようとしている。
さらに、SOAP=メッセージプロトコルレイヤーを追加すると、この 'pig'の日付を '強制'されたWebアプリにパフォーマンスヒットが追加されます。 MVC-4アプリは、そのようなDALを使用するように指示されています。新しいユーザーストーリーが発生するたびにWebMethod署名とSP署名の両方を変更する必要があります。このようなパススルーアプローチには、2つの緊密に結合された層が固有です。
一般に
- Webサービスレベルは、複数のアプリケーションの一般的なデータ要求の再利用を促進します
- Webサービスは、アプリケーションレベルの開発から生じる多くの問題をそらすバージョン管理を使用して設定できます。たとえば、既存のアプリケーションを使用するプロジェクトを初めて使用する場合、既存のデータベースソースを使用するようにアプリケーションを構成するための適切なモデルとして使用します。
- Webサービスは、単純なURIを使用することにより、リクエストを送信し、JSONなどの一般的な形式で応答結果を取得するための柔軟なオプションを許可するように進化しました。これは、信頼できる統一インターフェースを推奨するより一般的な標準を使用してクライアントアプリケーションを開発できることを意味します。
私はちょうどASP.NET Web Apiに注目し、最初にデータサービスを作成する予定です。
私は最近、エンティティフレームワークを使用した.NET MVC Webアプリケーションに注目しています。
- 既にMVCを使用している場合、Web ApiはMpiとApiコントローラーも使用するため、サービスを構築するための学習曲線は非常に簡単です。
私は最近、もともとOracleのストアドプロシージャに基づいて構築していたMVC Webアプリに苛立ちを感じていました。 Oracle 9またはそれ以前の元のバージョンでは、Visual Studio 2012で別の問題が発生し、Web config接続とTNS名に基づいて使用する適切なdllファイルを検索するロード時アセンブリを使用した、より現代的な接続ファクトリアプローチを推進しました。
データベースへの接続に失敗し、「サポートされなくなりました」エラーメッセージが表示されました。好奇心から、Oracle 12cをダウンロードし、TNS名とロードアセンブリdllでうまく機能するアプリケーションレベルの接続をいくつか作成しました。Oracleで問題なく作業できました。
古いOracleバージョンへの接続で動作するいくつかのWebサービスが構築されました。それらは選択されたテーブルに特別にマッピングされたメソッドで構築されましたが、私の期待はずれになりました。私は自分で書かなければなりません。
Oracleデータベースの保守を担当するグループは、クライアントインターフェイスとビジネスロジックレイヤーを抽象化するために使用していた古いストアドプロシージャを置き換える新しいストアドプロシージャを作成することになると言われました。
したがって、最初に考えたのは、ドロップダウンリストの記入やエンタープライズ全体のデータのオートコンプリートなどの一般的なデータ要求はすべて、Oracleストアドプロシージャを呼び出すデータサービスを通じて行われるということでした。各アプリケーションでこのプロセスを繰り返し、各開発者が構成とバージョン/ロードアセンブリに苦労するのはなぜですか？
そう....
- 通常、SQL Serverのデータ使用にEFを使用している可能性のある.NET MVCアプリケーションでOracleストアドプロシージャを使用するなど、複数のデータベースサーバーの問題については、これらの頭痛をWeb Apiサービスメソッドに押し上げて、構成の問題を特定できるようにします。
- この場合も、Web Apiを使用してSQL Serverデータリクエストを行う場合、すでに使用しているJavaScript、JQuery、およびJSONを使用してクライアントインターフェースを実行できます。
私はアプリケーション開発者/アナリストであり、DBAではありません。そのため、私の視点は、データベースツールの進化時にアプリケーションを絶えず修正しなければならないという不満のない経験から得たものです。