Web サイトにはウィザード スタイルのフォーム アプリケーションがいくつかあり、各ページでユーザーから情報を取得し、Web サービスを使用してバックエンド プロセスに送信します。
残念ながら、各フォーム送信中に情報をまとめて送信することはできないため、プロセスの最後までユーザー セッションに情報を保存し、同時に送信する必要があります。
サーバー メモリ/SQL サーバー ディスク スペースの量は、ユーザー セッションに保存できる量に対する唯一の制約ですか、それとも他に考慮すべきことがありますか?
編集: このサイトは ASP.NET Web フォーム上に構築されています。
情報が機密ではないと仮定すると、情報を Cookie に保存できます。これにより、サーバー側に保存する必要がある情報の量を減らすことができます。これにより、JavaScript を介して情報にアクセスすることもできます。
または、viewstate を使用して情報を保存することもできますが、これはサーバーとクライアントの間で大量のデータが送信される可能性があり、私の推奨するソリューションではありません。
保存する必要があるセッション情報の量は、アプリケーション、予想されるユーザー数、サーバーの仕様などによって大きく異なります。より正確な回答を得るには、より多くの情報が必要になります:)
最後に、プロセス全体で収集された情報がページごとに必要でないと仮定すると、すべての情報をデータベース テーブルに格納し、レコードの一意の ID のみをセッションに格納できます。各ページが送信されると、db レコードが更新され、最終ページですべての情報が取得されて送信されます。必要なデータベース読み取りの数が原因で、後続の各ページで以前の情報を取得する必要がある場合、これは考えられる解決策ではありません。
HTMLフォーム全体を含む1つのaspページを作成し、ユーザーが表示部分に入力して「送信」するまで、その一部を非表示にすることもできます...
次に、入力された部分を非表示にして、フォームの次の部分を表示するだけです...
これは、.NET フレームワークでは非常に簡単です。「ウィザード ステップ」ごとにパネルを使用し、各パネルをいつ表示および非表示にするかのロジックを追加します。
これで、すべてのデータが 1 ページに表示されます。
ユーザー Session オブジェクトに大量のデータを格納することはパフォーマンスの観点から問題があるため、ASP.Net は上記の投稿で言及されているものに加えて、いくつかの他の回避策を提供します。ASP.NET プロファイル プロバイダーを使用すると、セッション関連の情報をデータベースに永続化できます。別のサーバーを使用してすべてのセッション情報を保存するセッション状態サーバーを使用することもできます。クラスターまたはロードバランサーを使用する必要がある場合、これらの状況は両方とも考慮されます。サーバーは、異なるサーバー間でセッション情報を認識できます。情報を Http Session オブジェクトに格納すると、1 人のユーザーがそのセッションで常に同じサーバーにアクセスしなければならないという問題が発生します。
従来の HTTP モデルを使用する場合 (つまり、runat="server" を使用しない場合)、データを別の ASP ページに投稿し、投稿されたデータを非表示のフォーム要素に配置することができます。セッション変数に何かを配置します。
セッション、ビューステート、データベース。これらはすべて遅いですが、仕事は完了します。
非表示のフォーム フィールドは、私が最も気に入っている答えです。
状態を保持する方法は他にもあります。Cookie、ポップアップ ウィンドウ、フレームセット、または iframe。