web-dev-qa-db-ja.com

ASP.NET MVCがセッション状態を使用するのはなぜですか？

ASP.NETチームがセッションの代わりにキャッシュを使用することを推奨したため、過去数年間、セッションを使用してWebFormモデルを操作することを中止しました。そのため、通常はweb.configでセッションをオフにします

<sessionState mode="Off" />

しかし、この設定でASP.NET MVCアプリケーションをテストすると、mvcフレームワーク内のクラスSessionStateTempDataProviderでエラーがスローされ、セッションステートをオンにするように求められました。セッションを使用しているソースを見る：

// line 20 in SessionStateTempDataProvider.cs
Dictionary<string, object> tempDataDictionary = 
httpContext.Session[TempDataSessionStateKey] as Dictionary<string, object>;

では、なぜここでセッションを使用するのでしょうか？何が欠けていますか？

================================================== ======

編集申し訳ありませんが、この投稿がセッションとキャッシュについて議論することを意味していませんでしたが、ASP.NET MVCのコンテキストでは、ここでなぜセッションが使用されるのか疑問に思います。この ブログ投稿 でも、Scott Watermasyskがセッションをオフにすることは良い習慣であると述べたので、これからMVCを使用するためになぜオンにする必要があるのか​​疑問に思っています。

asp.net-mvcsession-state
33
Ray

セッションはTempDataストアに使用されます。 TempDataは、非常に制限された形式のセッション状態であり、特定のユーザーからの次の要求までのみ持続します。 （編集 MVC 2+では、次に読み取られるまで持続します。）TempDataの目的は、データを保存してからリダイレクトを行い、保存されたデータをユーザーが実行するアクションで使用できるようにすることです。リダイレクトされました。

TempDataストアにSessionを使用することは、Sessionをすでに処理している分散キャッシュシステムがTempDataで機能することを意味します。 TempDataが行うときにSessionを直接使用しないことには、いくつかの利点があります。 1つは、自分でセッションをクリーンアップする必要がないことです。 TempDataはそれ自体で「期限切れ」になります。

33
Craig Stuntz

セッションではなくキャッシュを使用することをASP.NETチームが推奨

@ ray247、これの参照を提供できますか？セッションとキャッシュは本質的に異なり、アプリケーションの要件に応じて使用する必要があります。たとえば、ユーザー固有のデータをキャッシュに保存すると、望ましくない動作が発生する可能性があります。もちろん、セッションの使用を本当に避けたい場合は、ITempDataProviderインターフェースの独自の実装を提供できます。

13
Darin Dimitrov

うーん...あなたは重いオブジェクトまたは比較的めったにアクセスされないオブジェクトの永続化について読んだかもしれません-それらをキャッシュに入れることは間違いなく良いですが、軽いオブジェクトまたはすべてのリクエストで必要とされるデータのためのより良いテクニックはありませんそれらをセッションに入れます。

セッションを正しく使用すれば、セッションは悪ではありません。

6
maxnk

ただ追加の考え。 TempDataには独自の目的があり、MSはTempDataの永続的なメカニズムに関してさまざまな考え方があることを知っていました。したがって、デフォルトでは、永続ストアをSessionStateにしました。しかし、デザインはまだ非常に柔軟です。プロジェクトのニーズとそれを導くガバナンスに基づいて、特定の要件に適合する独自のtempdataプロバイダーを作成できます。

これがリソースへのポインタです TempData

TempDataの実装におけるその他の改善点を以下に示します TempData Improvements

以下は、MS Velocity Distributed Cachingを使用した代替実装です。 Velocity TempDataプロバイダー

3
rajesh pillai