はなぜMicrosoftはPerRequestLifetimeManager

Question

https://msdn.microsoft.com/en-us/library/microsoft.practices.unity.perrequestlifetimemanager(v=pandp.30).aspxを使用してから警告んがのように述べている：

PerRequestLifetimeManager寿命マネージャが正しく動作し、HTTPリクエストの範囲内ステートフルまたはスレッドセーフでない依存関係での作業に役立つことができますが、それ誤った使い方をしたり、誤って使用するとエンドユーザのアプリケーションコードにバグを見つけにくいことがあるため、避けることができるときには使用することはお勧めできません。登録する依存関係はステートレスであり、HTTPリクエストの存続期間中に複数のオブジェクト間で共通の状態を共有する必要がある場合は、次のItemsコレクションを使用してこの状態を明示的に格納および取得するステートレスサービスを持つことができます。現在のオブジェクト

どのようなバグや悪い習慣が、警告の対象ですか？どのようにそれを間違って使うのですか？ - 残念なことに、この警告はあまり具体的ではないため、現実世界に適用するのは難しいです。さらに、この文脈でどのようなステートフルな手段が私には明らかではありません。

IMHO PerRequestLifetimeManagerを使用する典型的なシナリオは、何らかの種類のデータベース接続（DbContextなど）または同様のものです。

Answer 1

その目的は、要求ごとに1つのインスタンスのみをインスタンス化することです（たとえば、1回の要求の過程で冗長な操作とルックアップを防止するなど）。

作成されたオブジェクトがリクエスト中に状態を保存するのに適していると仮定した場合、危険です。依存性注入のアイデアは、あるクラスが依存関係（一般的にはインターフェース）を受け取り、そのインターフェースを実装することを除いて、それについて何も知らないということです。

しかし、オブジェクトが要求の存続期間中存続する場合は、リクエスト中に状態を維持するのに適していると考える人もいます。そこで、あるクラスが依存関係を受け取り、その中にいくつかの情報を格納し（プロパティの設定など）、別のクラスが同じ依存関係を受け取り、そのプロパティを読み取ることを期待するという複雑なシナリオを作成します。

ここで、依存関係の注入（デカップリング）の目的は、その依存関係の存続期間についての組み込みの前提を持っているため、他のクラスが行ったことや、そのオブジェクト。これは、クラス間の相互作用が知覚することが難しい（たとえ隠されていても）難しい混乱を招きます。したがって、簡単に破ることができます。

誰かが、その依存関係のライフスタイルがWebリクエストではなく一時的であると判断したとしましょう。突然、それに依存するクラスのすべての動作が期待どおりに動作しなくなります。開発者はそのクラスを見て、何も変わっていないことを確認します。何が起こった？これらのクラス間のやり取りは最初は分かりにくいので、問題が解消されると見つけるのは難しいでしょう。その依存関係のライフスタイルが変わった理由があったなら、問題は修正するのがさらに難しくなります。

リクエスト中に状態を保存する必要がある場合は、HttpContextのような「通常の」場所に配置する必要があります。紛らわしいいくつかの練習やバグのためにまだそこに余裕がありますが、少なくとも、私たちはHttpContextが（定義によって）特定の要求に結びついていることを知っています。