会社のとある研修で - 技術ごった煮

画面間の引継ぎ情報の設計どうする？っていうネタ。

クライアントでhiddenで持つとか。
サーバー側で持つとか。
データベースで持つとか。

新人の頃のプロジェクトでは、クライアントで持ってました。
2〜3年目の頃のプロジェクトでは、データベースで持ってました。
最近やってるPJでは、クッキー＋サーバー側で持ってます。

冗長構成でフェールオーバーなんていう、セッションレプリケーションは
サーバーとして、そういう仕掛けを持ってたりするので、
それ使っちゃうのが一番楽チンだ、とか。

ワークショップやってて面白かったところ

① 一覧画面→詳細画面→｢キャンセル｣ボタンで一覧画面に戻す

　一覧画面は1〜50件まで、51〜100件まで、、
　なんていう風な制御になってるとして。

　｢キャンセル｣ボタン押されたら、どうやって戻す？っていう。

　・データベースにもう1回取りにいく
　→その間にデータベースの件数の増減の影響を受けて、
　　例えば50件目のレコードを選択してたとしたら、
　　それが51件目になってしまったら、そのページに自分が選択した
　　レコードは表示されていない
　　⇒夜間バッチでしかデータベースの情報が変わらないようなものだったら
　　　いいのかもしれないですけどね。
　　　あとは、必ず1ページ目(1〜50件)に戻すようにする、とか。

　・キャッシュに持つ
　→50件分くらいだったらよくね？
　　⇒キー情報だけキャッシュに持たせて、
　　　画面表示情報はその時に取得させるような仕掛け作れば。

② 同一プロセスで複数画面(タブとかCtrl+Nとか)対応

　何もしないと後勝ちになってしまう。
　[画面1]で数量が2。
　[画面2]で数量が1。
　[画面2]を表示したのが後だとして、
　でも登録ボタンを押したのが[画面1]だったとすると、
　オペレーションした人は数量は2だと思ってるのに、
　実際登録された内容は数量1っていう。

　・登録ボタンを押す画面表示にIDを付ける
　→登録ボタンがある画面を表示するときにIDを振って
　　それをセッションに保持してから
　　クライアントにレスポンスを返す。
　　クライアントはhiddenフィールドにそれを保持して
　　登録ボタンが押されたら、hiddenフィールドからリクエストされたIDと
　　セッションのIDが一緒じゃなかったらダメ。
　　⇒ブラウザの戻るボタン禁止令？

この1年半くらい、ほぼバッチばかりやっていたので。
久しぶりにこういうこと考えました。

Amazonとか、どうなってんだろうって。
こういう仕掛けは自力で考えるのもいいですけど、
どこでも似たようなことやってるんだから、
それに従っちゃうのが一番なのかな、、と思うのですが。。