Webセッションは「悪いデザイン」ですか？どうして？

先日、同僚と話し合っていたところ、彼はWebアプリケーションでユーザーのセッションを使用するのは間違っていると言っていました。格納している情報によっては間違っている可能性があると答えました。それ以外の場合は、MicrosoftがWebセッションサービスを提供する必要があります（ASP.NETについて話していました）。

彼は、MSでさえ、デザインが悪いと簡単に返信できると再度答えました。そして、彼はそれを示すいくつかのホワイトペーパーを見せてくれた。

残念ながら、この人に連絡する機会はもうありませんが、彼の視点についてもっと理解したいと思います。誰もがそれについての情報/視点をここに持っていますか？

私は彼が「悪い設計」を「悪い練習」ほど意味したとは思わない。一般的に、Webアプリケーションは可能な限りステートレスでなければなりません。たとえば、ページの閲覧を許可するためにユーザー情報を知る必要がある場合でも、その情報はCookieの形式でクライアントマシンに保存でき、サーバーは毎回ユーザー情報を検証するだけです。

これは理想的ですが、クライアントが常にCookieを保存できるとは限りません。さらに、ステートレスな方法でユーザーを検証します。これには、単純なページ要求のためにデータベースから情報を照会することが含まれます。多くの場合、セッションにそのような情報を保存する方が簡単です。

ただし、Rubiconを通過すると、多くのプログラマーがセッション内の認証情報だけでなく、他の多くの情報も保存しようとします。これはアンチパターンであり、Webアプリケーションを状態に大きく依存させる傾向があります。これは、そもそも避けられるべきものでした。

一部のプログラマーは、Springなどのテクノロジーに依存して（Javaを使用している場合）、そうでなければ依存関係の混乱を解消しますが、依存関係を排除するのではなく、依存関係を作成する方が簡単になると主張します。このようなテクノロジーは、アンチパターンの問題を減らすのではなく、開発を支援するものでなければなりません。

したがって、良い経験則として、ステートレスで記述できる場合は、そうすることをお勧めします。そうしないと、このトラップに陥る危険があります。当然、これが必要な状況に陥りますが、一般的に言えば、再取得が困難な情報のみを保存する必要があります。

2つの異なるトピックを混同していると思います：1）セッションと2）asp.net Webフォームのページモデル

ユーザーの認証にはWebセッションが必要です。セッションは、この目的にのみ使用するのが理想的です。ユーザーデータをセッションに保存することはできません（サーバー上、Cookie内、またはasp.net/webformsが行うように：ページ自体内）。Webセッションが悪いと言うべきではなく、ユーザーデータを保存するセッション中は悪い習慣です。ユーザーデータをサーバーに保存しない理由には、グローバル変数を避けるための同じ理由が含まれます。ユーザーデータをCookieまたはページに保存すると、セキュリティ上の問題が発生する可能性があります。asp.netのページモデルを使用することは、Webのステートレスな性質にも準拠しません。Webフォームが悪いデザインである理由をさらに調べるには、検索を行うことができます。一方、セッションはWebアプリケーションに必要な部分です。

コントロールとページ上のセッション状態の保存は、本質的にハックです。MSの場合-winform環境でできる限りページを設計できる開発環境を提供できるようにしたかったため、必要なものです。

MSはそれ自体がMVCアーキテクチャ（最新バージョン-MVC 4）に移行しました。これは、プロトコルが実際にあるべき状態-ステートレスへの回帰です。

状態の保存がまだ便利な状況もありますが、これはルールではなく例外であることを理解する必要があります。