Webサービスを使用してデータアクセスレイヤーをラップするのは本当に悪い考えですか？

Question

納得できません-Webサービスの上にフロントエンドアプリを構築できるさまざまな消費者にデータを公開することが役立つと思います。

データアクセスレイヤーをラップするためにWebサービスを使用するのは悪い考えのサンプルを提供できますか？

Answer 1

「データアクセスレイヤー」として定義する内容に応じて、適切な理由がある場合とない場合があります。従来、WebサービスやRPCレイヤーなどの分散APIは、次のレイヤーに存在します。これには次の利点があります。

1. DBへの密結合なしで、この層を調整して、分散アクセスをうまく再生できます。たとえば、ラウンドトリップを最小限に抑えるためにAPIを編成します。

2. 追加の検証レイヤーをAPIに追加できます。生データアクセスレイヤーは、不正なデータをシステムに書き込むことを許可する場合があります。このため、信頼できないクライアントに公開するのは悪いでしょう。

3. アプリケーションレベルのセキュリティは、データアクセスレイヤーでは不可能な方法でサービスレイヤーに配置できます。

4. ポイント1および2は、中間層でビジネスルール検証を再利用することを意味します。

データベースサーバーに直接接続することにより、CRUD操作用の単純なAPIを公開することもできます。そのため、この上にあるWebサービスレイヤーは、DBMSがまだ提供していないものを提供しません。一部のDBエンジンは、HTTPを介してクエリを直接処理することもできるため、ほとんどのファイアウォールを介してクエリをトンネルできます。ただし、これのセキュリティ面は、ほぼ確実にこれを公開インターネットに公開したくないことを意味します。

理論的には、Webサービスを介してCRUD操作（「データアクセスレイヤー」を意味すると想定しています）を公開することはできますが、これを行わないかなり正当な理由があり、そうすることのメリットは比較的少ない。

Answer 2

今日の世界における主要な推進は、クラウドまたはSaaSコンピューティングに向けられています。

このことを念頭に置いて、SalesForce（CRM）、Google、Parature（ヘルプデスク）などの多くの主要なアプリケーションは、Webサービスを介してアプリケーションを公開します。

これは良いアイデアではなく、アプリケーションを環境に統合しようとしている企業にアプリケーションを真剣に考えさせる唯一の方法です。

とはいえ、Webサービスを利用してDALをラップするときに考えられる唯一の例は、1つのアプリケーションだけがDALを呼び出し、それが直接開発管理下にある場合です。これは、Webサービスの境界を越えてデータをシリアル化/逆シリアル化することでパフォーマンスが低下するためです。

Answer 3

まあ、セキュリティなしでAPI全体をWebサービスで公開しているのなら、それは悪い考えかもしれません。

ただし、必要な部分を安全で読み取り専用の方法で公開し、顧客がそれを好むのであれば、それは間違いなく良いことです。

経営陣を説得する必要がある場合は、「Googleがやる」ことを忘れないでください

Answer 4

.NETでは、WCFはChrisが言及したパフォーマンスヒットを回避する方法を提供しているようです。 WCFを使用すると、データアクセスコンポーネントを独自のアプリケーションのインプロセスで実行できるようにするだけでなく、Webサービスとして簡単に公開することもできます。 （免責事項：実際にこれを実装したのではなく、見ただけです。）