これはかなり自由回答形式の質問セットです。それは悪いことではありませんが、「正しい」直接的な答えはあまりありません。しかし、注意すべき点がいくつかあります。一部の選択肢は、信頼性の要件などによって異なります。
たとえば、リクエストを処理しているスレッド プールを枯渇させることを参照して、"iis を台無しにする" ことのないメソッドが必要です。これを行うには、スレッド プール外のスレッドで作業を行う必要があります。これは、要件と測定されたパフォーマンス特性に応じて、適切と思われる方法で行うことができます。次の 2 つのオプションがあります。
- タスク並列ライブラリ (TPL)、新しいスレッドなど、何らかの方法で新しいスレッドを開始します。
- 別のプロセス (Windows サービスなど) でレポート生成をホストします。
選択したフレームワークに組み込まれた非同期サポートを使用する 3 番目のオプションもあります。MVC の場合、非同期コントローラーがあります。回答を送信する前にレポートが完了するのを待ちたくないと言ったので、これをオプションとしてリストしません。非同期コントローラー/ページは、ここでは何も購入せず、実際には害を及ぼします。
信頼性に関しては、反対側のことも考えなければなりません。はい、iis を台無しにしたくありませんが、iis があなたを台無しにすることも気にしますか? Web プロセスはリサイクルできます。または、他の理由でダウンした場合、レポートの生成も停止します。これが重要な場合は、サービスの信頼性を個別に制御できるように、リカバリ メカニズムを配置するか、アウト オブ プロセスでホストする必要があります。
アウトプロセスでホストするもう 1 つの利点は、そのプロセスをフロントエンド アプリケーションとは別のサーバーに物理的に展開できることです。その後、フロントエンドとは関係なく、そのアプリケーションからスレッド プールを使用するように最適化できます。また、一度に多くのことが行われている場合は、コンテキストの切り替えが減少します。さらに、必要に応じて、レポート生成プロセスを個別にスケールアウトできます。最後に、Excel などの自動化に関する権限やその他の問題を個別に処理することができます。
アウトプロセスの欠点は、複雑さが増すことです。おそらく、WCF の一方向呼び出し、メッセージ バスなど、要件に合った通信が必要です。このコストとニーズ、および信頼性/スケーラビリティなどから期待される価値を比較検討する必要があります。
さて、非同期作業を行うためのツールの選択は、主にあなた次第です。私の意見では、TPL は非同期作業に対するかなり優れた抽象化であり、タスクを実行するためのデフォルトのタスク スケジューラはスレッドの使用について非常にスマートであるため、ほとんど考える必要はありません。また、.NET 4.5 にはコンパイラ サポートが組み込まれて出荷されており、TPL の操作が現在よりもはるかに簡単になり、より同期スタイルのように見えます (async/await を検索するか、例としてここから開始してください)。
要するに、一般的にどのテクノロジ スタックを使用するかについて、あまり緊張したり麻痺したりすることはありません。機能以外の要件 (パフォーマンス、スケーラビリティ、信頼性など) をリストします。要件に適合する組み合わせを見つけて、1 つを選択します。間違った選択をするのではないかと心配している場合は、この領域の変化に効率的に対処できるようにソリューションを構築してみてください。必要に応じて、いつでも測定して後で変更できます。