第３回は画面遷移とセッション管理について説明しました。

クラウドが最近はやっています。私も使っていますが、gmailに代表されるWebメールはとても便利ですが、ログインしてからログオフするまでずーっと自分のデータを操作できるのはなぜなんだろうと疑問に思う方はいませんか？

Webの世界は基本的に１回こっきりの世界です。RequestしてResponseが帰ってきたらサーバはすべてを忘れてしまうのです。だから、もう一回、アクセスしても前にアクセスしたことなんて忘れています。
なのに、ログインしてからログオフするまで、メールを書いたり、読んだり、削除したり、整理したり、、、と全部、ログインした人の情報を操作できます。当たり前じゃん。。と言われたらおしまいですが、これをどうやって実現しているのかを今回、説明しました。

今回はログイン画面を作って認証を行い、ログインできたら前回作ったTwitter画面を表示させ、ログインした名前を右上に表示させ、Tweet（発言）したときにはユーザ名をデータベースに書き込みます。

なのでログイン用のWebフォーム(TwitterLogin.aspx)とTwitter画面(TwitterFake.aspx)との画面遷移処理と、ログインした情報をずっと持ちまわる必要があります。

まず、ASP.NETは自分自身にしかアクセスできない特徴があります。これをポストバックと言います。
なので、ログインボタンを押しても、サーバで処理しなければそのままログイン画面が表示されます。

これを踏まえて画面遷移は２つの方法があります（図１）

図１ RedirectとTransfer

１．Redirect方式
Redirectはいったん、クライアントに処理を戻しクライアントが別サイトへアクセスする手法。
主に他のサーバに遷移する場合に使用する。データの受け渡しはGETで行う。

２．Transfer方式
サーバ上で他のWebフォームにアクセスする方法。他のWebフォームは呼び出されるとPageLoadイベントが発生する。PageLoad内で遷移元のPageクラスのメンバにアクセスできるため、データの受け渡しが可能。

１，２どちらとも画面間の受け渡しは可能です。ただし、これではたとえばログイン情報のようにずーーっと受け渡していきたい情報はどうするのか？
ここで便利なのが、Sessionといわれる考え方です（図２）

図２ Sessionの考え方

Sessionとはサーバ上でブラウザ単位にデータを保持する考え方です。
冒頭にサーバはクライアントからの接続が遮断されるときれいさっぱり忘れてしまうと言いました。
これを解決するための技術で、サーバからIDを採番して、クライアントに返します、これをSessionIDといいますが、このIDをクライアント（ブラウザ）はサーバにリクエストするときに毎回、SessionIDを送ります。なので、サーバは常にどのクライアント画から来たのかわかるのです。
これにより、セッションデータと言われるデータをサーバ上で格納すれば特定のブラウザの情報として認識できるようになります。ログイン情報などは以下のようなコードによって、セッションデータに保持可能です。

Session("UserID") = "toyoshima"

Sessionデータは連想配列（ハッシュテーブル）という構造でできていて、キーに対して値を設定するという形をとります。なので、以下のコードで上記で設定した"toyoshima"という文字列を取得できます。

Dim user As String = Session("UserID")

※第３回は時間切れでここで終了しました。しかしながら、まだ話してないことがありますのでいずれどこかの機会でお話しします。

＜今回できなかった話＞
・ViewStateスコープ
・Applicationスコープ

第３回 初心者向けASP.NET勉強会ログ

第３回初心者向けASP.NET勉強会ログ