mvcのnetcore依存性コンテナを、1人のユーザーにつき1つのインスタンスで設定する方法が不思議です。 https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection#service-lifetimes-and-registration-optionsそこによればユーザーごとのnetcore依存性注入
現在寿命を指定する3つだけ方法である：シングルトン（アプリケーションごとに1つのインスタンス）、（HttpRequestの内で共有つのインスタンス）をスコープ、過渡的（一例DIインスタンスごとに要求）
い誰かがまだインスタンスごとに作成を試みましたか？私はそれがどのように行われたのか不思議に思うだろう - そうでない場合、私はおそらく、ある時点でドキュメントを掘り下げて、それがどのようにして解決策を共有するのか見てみるだろう。
最初のユーザーリクエストでインスタンスを作成し、有効期限が切れるまで（次のリクエストでは）これを維持します。これはSessionsのように見えます。
サービスを工場で登録し、現在のセッションを分析することができます。
それは確かに私はしたくないと思う依存関係注入関連サービスをセッションにオフロードする。私はそれを心に留めておきます。 – Dbl
あなた自身に正直である - DIとセッションを混在させる何かを探している。どんな名前を付けても、それは本当です。ユーザースコープです。つまり、独自のスコープ（DIの点で）を作成してセッションに入れ、このスコープから他のサービスを解決するなど、さまざまな方法で実装できますが、ユーザーごとにメモリを使用する「セッション」メカニズムを使用しますwebfarmでは動作しません（サービスをシリアライズして複数のプロセス/マシン間で共有することはできません）。これが気に入らなければ（スケーリングには悪い）、アーキテクチャを再検討する必要がありますか？ – Dmitry
私はあなたに部分的に同意するが、私はまだそれを混ぜることを望んでいない。実際に私のDIが依存していると思われる予期しない余波は、セッションを無効にすることから解除するDIは、一意の要求IDです。 – Dbl
リクエストごとにインスタンスを作成します（ユーザーごとではありません）。このインスタンスは、要求の存続期間中利用可能です。インスタンスをどのように使いたいかについて詳しく説明できますか？ – alltej
私は基本的に私は残りのAPIの資格情報を入力するログインコントローラを持っています。これらの残りのクライアントインスタンスは、ログイン時に渡された資格情報で初期化されます。したがって、私の計画は、ユーザーごとに一度クレームID内に保存されたログイン情報を使用して、インスタンスのファクトリレジスタを使用することです。これはすでにスコープごと/要求ベースごとに機能しますが、パフォーマンス面で最適です。 – Dbl
（1）タイムアウトのあるメモリキャッシュ。 （2）トークンをキーとするシングルトンスコープの辞書（セッションID？） - 手動クリーンアップが必要です。 （3）[CookieTempData]（https://luisfsgoncalves.wordpress.com/2016/07/29/cookie-based-tempdata-for-asp-net-core/） – Dmitry