18

ほとんどの場合、トラフィックは少ないですが、高度に専門化された Web アプリケーションを開発しています。通常、L2S、EF、または nHibernate をアクセス レイヤーとして使用し、Asp.Net MVC をそれにスローします。通常の crud 操作では、ISession/DataContext を直接クエリしますが、より高度な機能/副作用については、ある種のサービス層。

ここで、OData (WCF Data Service) を介してデータを公開し、コントローラーから (または適切なテンプレート エンジンが表示された場合は jQuery から) クエリを実行し、WCF サービスを介して (またはカスタム メソッドとして) サービス操作を公開することを考えていました。 WCF データ サービスで?)。このアーキテクチャにはどのような利点/欠点がありますか?

複雑さと待ち時間の増加以外に何か得られるものはありますか? 関心のより良い分離 (またはそれは単なる幻想ですか)?

編集： たとえば、完全なajax駆動型ソリューションを作成することは良い考えでしょうか。WCF RIA サービス? それとも、柔軟性を失いすぎていますか? ロジックからビューを完全にディスパッチできるように感じたら、純粋な HTML を書くだけでいいので、asp.net MVC さえ必要ありませんか? しかし、新しい問題がたくさん発生していると思いますか？

4

5 に答える 5

32

しないでください。申し訳ありませんが、これはばかげた過度に設計されたアプローチです。あなたは 1 つのプロセスに入っているのに、ネットワーク接続を実行し、すべてのデータを XML にコーディングしてバックアウトし、さらに限られたクエリ セマンティクスで HTTP 接続を介して実行することを主張しますか? 試したことは誰にも言わないでください。

ここでは、関心の分離は錯覚です。高度に最適化されたドメイン モデルを簡素化されたデータ レイヤーに置き換えます。

つまり: 私は OData が大好きです。しかし、これはイン プログラム テクノロジではなく、ASP.NET MVC のようなフロント エンド テクノロジです。エンド ユーザー向けではなく、別のプログラムがデータに統合するためのものです。これは、同様のシナリオで使用する必要があり、信頼境界を越えてデータを公開する場合に使用する必要があります (たとえば、Silverlight は、要求が偽造される可能性があるため、信頼境界です)。

NHibernate のようなインプロセスのハイエンド アプリケーション ランタイム レイヤーを置き換えるように最適化されていません。

于 2010-03-23T09:47:23.673 に答える
20

TomTom が言及しているように、プロセス内で OData のループバックのコストを支払う必要はありません。データベースへの直接の視線があり、それが独自のアプリケーションのデータベースである場合、WCF Data Services を中間に配置する理由はありません。あなたが言及した他のオプション（L2S、EF、nHibernate）のいずれかを引き続き使用します。

ここで、他のアプリケーションが使用できるように http エンドポイントを介してデータを公開する必要がある場合、またはクライアントにサーバーからのデータにアクセスする必要がある jQuery コードがある場合は、独自のアプリケーションでさえも、OData エンドポイントが確実に役立つ可能性があります。 WCF Data Services は、これを作成する最も簡単な方法です。

于 2010-03-30T00:03:57.390 に答える
2

TomTom には多くの票があり、説得力のある口調にもかかわらず、彼は間違っていませんが、正しくもありません。

この特定の例では、OP はイントラネット LOB スタイルのアプリを作成しているように見えますが、これはおそらく、基盤となるデータベースを模倣する OData サービスによってのみ妨げられると思われますが、基盤となるデータベースを模倣していなかったらどうなるでしょうか?

彼がさまざまな、または未知の将来のデータ ソースに基づいてアプリケーションを構築していた場合、クエリの大部分が最終的に隣の部屋の SQL Server に戻ったとしても、サービス レイヤーはそれらのサービスを統合、再提示、簡素化、および集約できます。

同様に、大規模なアプリケーションを構築している場合、規模とは、1 時間に数百万の FX 取引ではなく、アクション間で数秒待機することを期待する何百万ものユーザーを意味する場合、アプリケーション間にサービス レイヤーを配置すると、データはよくあるパターン。インターネットのスケーラビリティは、多数の小規模なステートレス HTTP サーバーとその間のキャッシュ インフラストラクチャに基づいています。

実際には、同じクエリが数え切れないほど実行され、人々はページを更新したり、同じリンクを何度もクリックしたりしています。多くの人が一度にそれを見ることができるわけではないので、実際に 10m の行を要求する人はいません。そのため、小さなページで作業すると、データの流れとリクエストのインターリーブが維持されます。また、サービス レイヤーの共有 RAM キャッシュや RAM データベースを導入する機会もあります。

データベースを分割したり、SQL とキー/値ストア間で分割したりする必要がある場合もあります。その後、中間層で結合を実行し、スケール アウトして、結合と計算負荷の高いものをデータベース サーバーからオフロードできます。

インターネット スケールのルールは、データベースがホット スポットであり、データベースに話しかけられないようにできる限りのことを行う必要があるということです。iPad、ISP プロキシ、IIS 出力キャッシュ、または Redis キャッシュのローカル HTTP キャッシュであっても、これらすべてのレイヤーが負荷を分散し、負担を軽減するのに役立ちます。

したがって、Carl が私のインタビューに来て、SQL ボックスの前に OData レイヤーを配置することを検討していると私に言った場合、彼の理由を聞きたいと思います。

于 2013-08-07T12:44:00.580 に答える
1

WCF Data Services と OData は JSON をサポートしているため、それを利用してペイロードを最小限に抑えることができます。さらに、WCF Data Services を使用すると、データ アクセスを完全に制御できます。Entity Framework をロールする必要はありません。すべてをカスタマイズできます。利点は、WCF Data Services と OData を使用して、プロトコル構造が完全に処理されることです。また、MVC からサービスを利用するには、サービス参照を追加する必要があります。WCF Data Services は WCF 上で実行されるため、OData タイプの配信だけでなく、他の Web サービスも実行できるため、非常に柔軟です。

OData の性質や、WCF Data Services が OData を処理する方法に伴う制限があちこちにありますが、それらはかなり具体的であり、アーキテクチャで発生した場合は回避する方法があります。

ソリューションが 1 つの Web アプリケーションに分離されている場合、そのアプリケーションにデータ レイヤーを埋め込むとうまく機能します。しかし、別のアプリやプロセスをデータ レイヤーや共有ビジネス ロジックにヒットさせる必要がある場合は、データ レイヤーを WCF データ サービスに配置するオプションを検討する価値があります。たとえば、2 行のコードで Web サービス メソッドを呼び出す PowerShell スクリプトを作成できます。そのため、Web アプリから、コマンド ラインまたはスケジュールされたタスクから実行できるドメイン ロジックがある場合、WCF データ サービス レイヤーは、ロジックやコードを複製することなく、そのシナリオをすべて処理できます。

猫の皮をむく方法はたくさんあります。私はビジネス アプリケーションで両方のアプローチを使用してきましたが、どちらか一方を避けるべきだとは言いません。どちらもうまく機能し、害を及ぼすことなく十分な価値を提供します。

于 2011-06-10T17:23:58.460 に答える
0

公平を期すために言うと、このアプローチには、確かに途方もないパフォーマンスの懸念を上回る利点があります。この方法で構築されたアプリケーションは、待機時間が桁違いに長くなり、インプロセス ソリューションよりも実行するコンピューティング リソースのコストが数倍になる可能性があります。

そうは言っても、人的資源が限られている開発シナリオでは、これがうまくいくかもしれません。これにより、請負業者をすぐに雇って、新しい画面やまったく新しいアプリケーションを自分に合った言語で非常に迅速に作成することができます。開発者は、独自の自社製ソリューションよりも速く最新の状態にできます。構成ファイル内の sa パスワード、必要に応じてカスタム セキュリティ レイヤーの挿入、統合されたログと監査、複数のデータ ストアを 1 つの一貫したリソースに結合する必要はありません。異種プラットフォームを使用している場合、SDK を作成する必要はありません。SDK は既に多くの重要な言語で作成されています。oData は MS Excel と非常によく連携します。これは、多くの組織にとって大きなメリットです。ネットワーク トポロジによっては、専用回線を使用するよりもインターネット経由でルーティングする方が安価で高速な場合があります。

大規模なデータセットの場合、リクエストとパッケージ化のオーバーヘッドはそれほど重要ではなくなります。たとえば、レポート シナリオの場合。私はこのようなものを設計したことはありませんが、企業文化と利用可能なリソースに応じて、oData エンドポイントを内部で使用することが役立つ場合があることは理解できます。

于 2011-04-05T01:16:06.883 に答える