私は基本的なRESTfulなサービスを書いており、このタスクにASP.NET MVC 3を使用することに決めました。私のアプリケーションは、ユーザーごとのサーバーへの永続的な接続を維持する責任を負うことになります（今のところ）。私はApplication_Startが（永続的な接続のように）静的/共有状態を登録する場所だと仮定していましたが、Unity.MVC3のドキュメントを読んだあと、各要求/応答サイクルが（Application_Startを呼び出すことによって）サービスの作成を引き起こすように見えます。ASP.NET MVC 3アプリケーションで共有状態を実装するにはどうすればよいですか？
ドキュメントI refer toは言う：リクエストごとに
を、1 UpperCaseService、1 LowerCaseServiceと1 ExampleContextはユニティ経由DependencyResolverによってインスタンス化されています。リクエストの終了時に、ExampleContextは自動的に他の文書を読んだ後
が配置されている、と私はすでに想定したものから、のApplication_Startは、AppDomainのあたりに呼び出されます生み出した（再び、これはどのように多くの近くにあるであろうと想定コアがサーバー上にあります）。
したがって、要求/応答段階に耐えられるサーバーへの永続的な接続を維持する効果的な方法は、IISサーバーが作成したすべてのAppDomains間で共有されます。
このWebサービスは、別のWebサイトでのみ使用されることになります。これは基本的に認証プロキシサーバーですが、将来的にはさらに多くのことを行う予定です。したがって、今後のリクエストが必要となるため、レスポンスをキャッシュすることはできません。また、再認証はオプションではありません。
IISでは、ディレクトリはアプリケーションとして定義されています。その「アプリケーション」はappPool（プロセス）にマップされます。多くのアプリケーションをappPoolプロセスにマップできます。プロセスでは、CLRはデフォルトのappDomainを作成します（プロセス内で管理された境界と考える）。あなたのASP.Netアプリケーションは、そのプロセスとそのappDomainで動作します - コアごとに複数のappDomainsではありません。各リクエストはスレッドプールから提供されます。 in-procの状態を保存すると、そのappDomain内のあなたのアプリにアクセスできます。 – bryanmac
しかし、あなたが懸念しなければならない問題は、appPoolsが（デフォルトで）リサイクルできることです。あなたの状態は脆弱です。どちらもあまりRESTfulではありません... – bryanmac
...多くのアプリはそのappPoolプロセス（ホスティング、共有管理）にマップできますが、あなたのアプリは1にマップされます。プロセスは別のアイデンティティなどとして実行する分離と能力を提供します。 – bryanmac