MVCのセッション

Question

セッション処理は、MVCの全体的な概念のどこに適合しますか？モデルかコントローラ？

Answer 1

SessionStateの目的は、ユーザーのセッションに関するデータを1つのHttpRequestから次のHttpRequestに永続化することです。場合によっては、これは、手動でクッキーを実装するか、セッション情報のデータストアを作成して識別子を渡すよりも簡単な解決策です。これを行うMVCの方法は、SessionStateをラップするTempDataを使用することです。つまり、コアインフラストラクチャの一部をオーバーライドしない限り、SessionStateに直接アクセスする必要はありません。私は、モデルをデータのより比喩的な表現として考える。モデルでsession-dataを使用するのはまったく正しいとは思われません。なぜなら、モデルはおそらくビジネスロジックを表していて、SessionStateが不必要に複雑になるからです。 System.Web.Mvcは、HttpContextを直接使用することなく状態を維持するための多くのメカニズムを提供します。これらのメカニズムは、ControllerContext、ActionFilterフィルタリングコンテキスト、ExceptionContext、AuthorizationContext、ModelBindingContext,RouteDataおよびViewContextのプロパティとして含まれています。それらは、セッション状態コレクションに格納する可能性のある別のものを、より論理的に区切られた区画に分けるのに役立ちます。

TempDataは、ControllerContextとViewContextから使用できます。これは、セッション状態機能へのアクセスポイントです。このデータの処理と書き出しを制御したい場合や、アクションフィルタが主な注入点であるかどうかはわかりません。この記事では、モデル状態をリクエスト間で自動的に維持するActionFilterの使用方法について説明します。http://blog.jorritsalverda.nl/2010/03/10/maintainable-mvc-post-redirect-get-pattern/私はそれが役に立つかもしれないと思う。質問はひどく具体的ではありませんでした...私があなたの質問に直接言及しなかった場合は、明確にしてください。

Answer 2

私はそれらをコントローラーレベルに保つか、カスタムアクションフィルターまたはモデルバインダーで非表示にすることをお勧めします。

セッション状態は実際にはWebクライアントのコンセプトです。私はレイヤリングのために自分のモデルから外しておくことを好みます。または、少なくとも私は自分のセッションまたはコンテキストのインターフェイスでそれをラップします。