MVC - リクエスト間のビューモデルデータの永続化

Question

私は、私が取り組んでいるプロジェクトで持っている問題について見落としてしまった、いくつかの提案や解決策を探しています。いくつかの要求の間にViewModelデータを永続化します。次に例を示します。

ユーザーは、いくつかのフォームフィールドと、基礎となるモデルに関連する項目のグリッドを含む特定のページにあります。ユーザーはグリッドにアイテムを追加する必要があるため、これらのアイテムの一部を選択するには別のページにリダイレクトする必要があります。ユーザーがこのページでアイテムを選択した後、アイテムをグリッドに表示して元のページに戻す必要があります。

私は、2番目のページにリダイレクトされる前に、元のページのViewModelをセッションに保存し、2番目のページの選択したアイテムにViewModelを適切に更新してから、元のページにリダイレクトし、セッションからのViewModelを使用してフォームフィールドとグリッドにデータを入力します。

しかし、私はこれが最適な解決策ではないと考えています。このプロジェクトはスケーラビリティが必要でスケーラビリティが問題になるでしょう。私は似たような質問をたくさん読んだことがありますが、自分の状況に本当に関係するものは何も見つかりませんでした。

このようなことを行ったことがあり、より信頼性の高い解決策を見つけたことがありますか、あるいは異なる実装についていくつかの提案があります。ありがとう。

Answer 1

これは基本的なウェブリクエストの制限であり、すべてのリクエストは本質的に「再開」です。セッションは、あなたがリクエストモデルを超えて物事を保存する場所を提供するために作られています。あなたがjavascriptを使ってはるかに高度なアプローチを取る必要がある限り、唯一のオプションです。

チェックアウトthis post私は既にリストを編集するための主要な解決策を取り上げており、その一部をここで適用しています。

あなたのケースでは、他のアイテムを選択するためのモーダル/ダイアログポップアップを使用することをお勧めします。これは、ページから完全に離れてナビゲートすることによって発生する大騒ぎを取り除きます他の場所では、部分ビューを簡単に再利用して、ダイアログや重複のないページでも機能させることができます）。 これは少しのjavascriptを含んでいますが、フォームが実際にページに表示されているので管理がずっと簡単になります。ほとんどの場合、遭遇したほとんどの場合、ユーザーエクスペリエンスが向上します。

また、他のページに隠れた入力を使用して、選択プロセスを通じてデータを送信する必要があります。これが醜くならない方法はたくさんあります。

結論として、セッションを使用することは、クライアント側のソリューションを作成したくない場合には唯一の選択肢です。私はjqueryがこれらのシナリオでもっと簡単に生活をしてくれたので、クライアントソリューションをお勧めしますが、それはもっと複雑です。

PSダイアログが最良の選択肢ではなく、セッションに固執すると判断した場合は、ステートサーバーなどの他のセッション記憶方法を使用してスケーラビリティを向上させる方法があるため、専用のSQLデータベースです。