セッションにまつわる失敗談

以下備忘録。

Tempdata衝突地獄

ASP.NET MVCのTempdataはSessionの代わりに使えて、かつ一度利用したら勝手に消去されるという使い勝手の良い存在です。リダイレクトする場合などに使えば効果抜群。
しかし、注意しなければならないのは以下のような書き方。

TempData.Add("hoge", "fuga");

TempDataに同じキーで２回Addしようとすると例外でコケます。だって当たり前だよね、TempDataって要はDictionaryなんだから！

TempData["hoge"] = "fuga";

このような書き方にすると、すでに同じキーで存在している場合は上書きしてくれます。上書きを気にしなくていいならこの書き方がオススメ。
まぁ普通はTempDataに同じキーで重複登録するようなパターンないはずなんですよ。普通は。

304地獄

これがドキツい落とし穴。「セッションを登録したはずなのに、リダイレクト先で『セッションが登録されていません』とエラーが出る」などという幽霊セッション。
この場合、「304 Not Modified」でサーバにアクセスしていない可能性が考えられます。
そりゃサーバにアクセスしていないんならセッションが登録できるはずがありません。

え？
「なんでセッションにデータ登録するようなアクションが304で帰ってくるんだよ」って？

GETでリクエストしてるからですよ。

GETリクエストなのにセッション登録させるようなポンコツPJがこの世には存在するのです……。

対策は二つ。POSTリクエストに改めるか、レスポンスにNoCache属性を付与するか。

複数画面表示によるセッションキー重複地獄

これに関しては正直避けようがない事態というか、

「この画面は複数表示させるようにして」って要求と
「この機能はセッション使うようにして」って技術上制約が

バッティングしちゃうのって往々にしてあり得る話だからもうしょうがない。
防衛策は設計段階で複数表示対応が必要かどうか早めに洗い出すしかありません。
開発後半になって対応させられる羽目になっちゃったりすると、思わぬデグレを引き起こしかねません。おぉこわいこわい。

なぜこのような地獄が発生するのか

だいたいモーダルウィンドウのせい。

モーダルウィンドウにある程度の規模のデータを受け渡そうとすると、セッション利用は避けて通れないため、必然的にこういうバグのリスクが高まります。
モーダルウィンドウはそれだけハイリスクな要素なんです。
同一画面上で極力済ませるようにする、それがダメならせめてモードレスにさせる、こういう外部設計での努力があなたの残業を減らすのです。頑張りましょう。