AcceptVerbsASP.NET MVC でフォーム エントリを処理するために、Scott Gu のプレビュー 5 ブログ投稿に詳述されている方法を使用しています。
だから私は使用する必要はありませんTempData。とはいえ、このプロセスに「確認」ステップを追加する必要があり、TempData.
何らかの理由で、私は使用することに嫌悪感を抱いていますTempData-それは設計されたものです。
これはまったく有効な懸念ですか、それとも私がでっち上げですか?
TempDataを嫌う必要はありません...しかし、正しく使用されていない場合は、設計が不十分であることを示している可能性があります。RESTful URLを使用している場合、TempDataは、POSTアクションからGETアクションにメッセージを転送するためのベストプラクティスです。このことを考慮：
URL Products/Newにフォームがあります。フォームPoststoProducts / Createは、フォームを検証して製品を作成します。成功すると、コントローラーはURL Products / 1にリダイレクトし、エラーが発生すると、products/Newにリダイレクトしてエラーメッセージを表示します。
Products / 1は製品の標準的なGETアクションですが、挿入が成功したことを示すメッセージを表示したいと思います。TempDataはこれに最適です。Post ControllerのTempDataにメッセージを追加し、ビューにifロジックを配置して完了します。
失敗した場合、formCollectionに入力された値とエラーメッセージのコレクションをPost ActionのTempDataに追加し、最初のAction Prodcuts/Newにリダイレクトしていました。ビューにロジックを追加して、フォーム入力に以前に入力した値とエラーメッセージを入力します。私には素晴らしくてきれいなようです！
TempData を使用する前に躊躇するのは良いことだと思います。TempData はセッションに保存されます。これは、次の場合に影響を与える可能性があります。
サイトに高可用性が必要な場合、セッション状態の適用に関して追加の考慮事項がありますが、これらはすべて解決可能な問題です。
私は、一時データを、ユーザーに通知するためのファイア アンド フォーゲット メカニズムであると考えています。彼らが最近行ったことを思い出させるのは素晴らしいことですが、一部のユーザー プロセスでそれを必須のステップにすることも躊躇します。その理由は、彼らがページを更新すると、それがなくなると私は信じています. まあ、信頼性が十分に定義されていないので、私もそれを使用することをためらっていると思います。
問題は、確認ステップの前にアクションが別のページにリダイレクトされていることでしょうか。代わりに、最初に送信した後、確認ダイアログを生成するのに十分な処理を行ってから、確認の質問で元のページを返すことができるのではないかと思います。検証を行う方法と似ていますが、検証ルールが確認ステップが実行されたかどうかをチェックする点が異なります (他の検証がパスするまで確認 UI は非表示になります)。
最初に TempData["model"] をチェックして返す GetModel メソッドがあります。それ以外の場合、GetModel はデータベースから適切なデータを読み込みます。
同じモデル データを必要とする別のビューを返す必要があるアクションがある場合、データベースからの余分な負荷を節約できます。
MVC3 のセッションレス コントローラーを確認してください。セッションを使用すると、単一のユーザーのリクエストの並列実行が妨げられ、パフォーマンスが低下することが判明しました。
tempdata はデフォルトでセッションを使用するため、この機能を使用することはできません。tempdata に Cookie を使用するように切り替えることもできますが、(少なくとも私にとっては) 少し厄介です。ただし、ビューステートよりはまだクリーンなので、それほど大きな問題ではないかもしれません。
これは、ViewData を使用するようなものであり、おそらくセキュリティ リスクではないことを意味します。しかし、TempData よりも ViewData を使用したいと思います。比較については、こちらをご覧ください: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/
設計に応じて、ユーザー/バスケットまたは必要なものをデータベースの一時データに常に保存し、完了したかどうかを示す「IsReady」フィールドを作成して、後で取り込みたい場合に拡張できるようにすることができます人々はブラウザを閉じることができることに注意してください。
なんでそんな嫌悪感を抱くの？このことは、単にその仕事をしてうまくいくことです:)
強く型付けされていないために気に入らない場合は、強く型付けされたインターフェイスを提供するラッパーをいつでも作成できます。
すべての良い答えは、メッセージを渡すためにこれを見たことがありますか。
ほとんどのセッションはメモリに保存されるため、TempData と Session は RESTful アーキテクチャの最良のアイデアではありません。したがって、サーバー ファームを使用する場合、ユーザー セッションは 1 つのサーバーに存在し、次の要求は別のサーバーに送信できます。
そうは言っても、ここでメッセージを渡すための TempData のこの使用法を見てください。
http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/
別のページへのリダイレクト アラートにのみ使用する場合、これをクエリ文字列アプローチを使用するように適応させることができます。