8

質問には負荷がかかっていると思いますが、フィードバックが必要でした。現在、dtos を介して Web サービスから poco クラス オブジェクトを構築しています。すべてのスカラー値をプリロードし、もちろんバイナリを含むすべてのコレクション/配列を遅延ロードします。

このライブラリは Web アプリケーションを駆動するものであるため、応答時間を改善するためにこれを行ったことは明らかです。ただし、サービスを再利用できるようにするために、各 GET 関数を単一のアクション (S) に正規化しました。たとえば、Active Directory からユーザー情報を取得することは 1 つ (たとえば、displayName や department などのスカラー値) であり、この人物の直属の部下を取得することは別の遅延ロード アクションです。つまり、オブジェクトを構築しているときに、このオブジェクトを構築するためにサービスが多数呼び出されるということです。一部のページは基本的な情報のみを必要とし、他のページは遅延読み込みメソッドまたはオブジェクト全体をさらに呼び出します。私はこれに問題があるとは思いませんが、私が疑問に思っているのは (そして職場の他の人はすでに批判しています)、これが問題になるかどうかです。

私の質問は、私はこれを間違っていますか？ただし、すべての入力を歓迎します。ありがとう

4

3 に答える 3

6

必要なバランスは、HTTP 呼び出しを行うオーバーヘッドと、大きな要求または応答を転送するオーバーヘッドです。

銀の弾丸はありません。たとえば、LAN を介してあるサーバーから別のサーバーに呼び出しが行われている場合、ペイロードが大きくてもそれほど問題にはなりません。呼び出しがモバイル デバイスから行われている場合、ペイロードをトリミングすると多くの利点が得られる可能性があります。

最初の最適なバランスは、Web サービスのメソッドをワークフローのステップとして見ることです。「X を達成したい場合、どのようなデータが必要か」について考えてください。それらの考えに基づいてリクエストの応答を絞り込み、結果を分析してください。これは出発点にすぎませんが、「すべての細部に 1 つの方法」または「すべてを許可する 1 つの方法」から始めるよりも優れています。

于 2012-07-09T15:54:26.143 に答える
3

私はこれに問題があるとは思いませんが、私が疑問に思っているのは (そして職場の他の人はすでに批判しています)、これが問題になるかどうかです。

問題は、サービスを呼び出すたびにオーバーヘッドが発生することです。より少ない、より大きな呼び出しで、より良い合計スループットが得られます。

ここには常にトレードオフがあり、バランスを取る必要があります。大規模な呼び出しは、必要以上のデータを取得するリスクを冒し、リソースの浪費にもなります。

于 2012-07-09T15:51:28.937 に答える
1

私はあまり頻繁ではない大きな電話に投票します。

あなたはWebコンテキストにいるので、データがデータストアからアプリ層、そしてWeb層にトラバースするためのコストのかかる操作であるため、ネットワークトラバーサルが最も多くのリソースを消費すると思います。したがって、（Web層のキャッシュメカニズムを介した）呼び出しの頻度が少ないほど、スケーリングが向上します。これは、個人的な経験によるものです。

また、「大」と定義するものは、アプリケーションの使用法によって異なります。たとえば、ユーザーの大多数が基本情報のみを表示し、一部のユーザーのみが直属の部下に入る場合は、2つの別々の呼び出しを使用できます。それ以外の場合は、1つに固執します。

お役に立てれば。

于 2012-07-09T16:05:03.530 に答える