私はいくつかの .com に取り組んできましたが、組み込みの ASP.NET セッション状態を使用したことはありません。有効なセッション チェックのために常に Cookie をチェックしてきました。セッションは DB にあるものや他の手段と比較されますが、最終的には Cookie です。ASP.NET ベースのセッション オブジェクトは使用していません。
では、なぜ人々はこのようなセッション状態サーバーのがらくたを MVC で使用しているのでしょうか? 私はそれの必要性を見たことがありません。
私はいくつかの .com に取り組んできましたが、組み込みの ASP.NET セッション状態を使用したことはありません。有効なセッション チェックのために常に Cookie をチェックしてきました。セッションは DB にあるものや他の手段と比較されますが、最終的には Cookie です。ASP.NET ベースのセッション オブジェクトは使用していません。
では、なぜ人々はこのようなセッション状態サーバーのがらくたを MVC で使用しているのでしょうか? 私はそれの必要性を見たことがありません。
私はそれの必要性を見たことがありません。
私も。Web アプリケーションで ASP.NET セッション状態を使用したことはありません。状態を導入するよりも、RESTful な方法でそれらを設計することを好みます。Web アプリケーションで最初に行うことの 1 つは、web.config に次の行を追加して、将来の開発者がセッションの使用を間違えないようにすることです。
<sessionState mode="Off" />
複数のリクエストにまたがる一部の揮発性データのストレージを簡素化するために、人々はそれを使用していると思います。
ASP.NET には、Cookie のセッション ID に対してチェックされるセッション ID によってインデックス付けされた SQL に基づくセッション状態があります。ASP.NET では、セッションをメモリ内に格納することもできます (既定)。同じビルディング ブロックが MVC で利用できます。
基本的に、あなたが実装したもの (「常に有効なセッション チェックのために Cookie をチェックしてきました。セッションは DB または他の手段にあるものと比較されますが、最終的には Cookie です。」) は、まさにあなたがうんざりしているものです! 車輪を再発明する意味はありません...
特定のユースケースに関しては、それを使用して、永続化する必要がある状態を処理できます。特定のケースでは、Cookieを保存してデータベースを検索する理由を確認してください-それはまさにセッション状態を使用する場所です(SQLまたはメモリに対して)
アクティビティがない場合のセッション タイムアウトの必要性をどのように処理しますか? Cookie はあまり安全ではありません。