ASP.Net MVC 3.0 で状態管理手法 (セッション、Cookie など) を避けるのは良い考えですか?
はいの場合、TempData 以外に利用できる代替手段はありますか?
1399 次
5 に答える
1
場合によります。
セッションと Cookie は何らかの問題を解決するために発明されたので、その問題を解決するために使用する必要があります。
Cookie はクライアント側に保存されるため、TempData は Cookie の置き換えにはあまり役立ちません。また、TempData はセッションですが、TempData はリダイレクト専用であるという違いがあります。TempData がリダイレクト シナリオで非常に有用である限り、これらのシナリオでセッションを有効にしておくことをお勧めします。
セッション指向のシナリオ (オブジェクトの作成に複数のステップがあり、最初のステップの後、まだデータベースに保存できないなど) がない場合は、使用を避けることができますが、一般的にそれ自体は悪ではありません。
于 2011-10-12T14:03:06.330 に答える
1
これは、特定の要件によって異なります。たとえば、セッション状態と Cookie は非常に異なる獣です。
セッション状態が WebForms の要件に適している場合は、MVC に適しています。MVC で使用しない特別な理由はありません。
基本的に、データを保存できる場所は、クライアント (Cookie/隠し値/クエリ文字列)、サーバー (セッション/キャッシュ/静的)、データベースの 3 つだけです。
これらすべての方法の長所と短所に関するドキュメントがたくさんあります。良い出発点は次のとおりです。
于 2011-10-12T14:02:12.773 に答える
0
リポジトリ パターンを実装すると、状態がキャッシュで適切に維持されることがわかりました。MVC Futures プロジェクトには、「ビュー ステートのような」ステート ストレージを提供する Html.Serialize メソッドもあります。 http://mvccontrib.codeplex.com/
Web フォームで自動的に維持されていたコンボボックスにバインドされたアイテムなどの情報については、データのリポジトリを呼び出すことをお勧めします。リポジトリは、キャッシュへの参照を維持します (理想的には、ICache のように作成したインターフェイスを介して)。次に、リポジトリは for ex に基づいてこのデータをキャッシュします。現在のユーザー名、キーは何でも。サービスレイヤーキャッシュを好む人もいますが、私は設計上、リポジトリレイヤーがこれを目的としていると感じています.
セッションはまだ使用されています-必要に応じて-その場所があります。セッションは多くの「悪い」ものに取り囲まれていますが、セッション固有の情報を保存する必要があり、サイトが 1 日に大量のヒットを気にしない場合は、おそらく問題なくヒットを受け入れることができます。
TempData は、「レコードが正常に保存されました」などの次のリクエストで表示されるステータス メッセージを保存するのに最適です。そのため、リダイレクトで失われることはなく、クエリ文字列で渡す必要もありません。それは私がそれを使用する唯一のことですが、次のリクエストで再バインドするためにデータを保存するために使用する人もいます.
于 2011-10-12T14:20:14.053 に答える
0
IMO、MVC のセッション状態のルールは WebForms のルールと同じです: 必要に応じて使用しますが、使用量は軽くしてください。ユーザー/セッションごとに追跡するデータが本当にある場合は、一からやり直す必要はありません。
于 2011-10-12T14:00:48.647 に答える
-1
状態をデータベースに直接保存できます
于 2011-10-12T13:54:02.650 に答える