第14章 Webプレゼンテーションパターン
ビューとコントローラの分離は、比較的重要ではなく、必要なときにだけ分離を実践することを推奨する。
なるほど、そういう考えもあるのか。
多くの人にとって基本的なWeb環境とは、静的なHTMLページである。
時代は、変わった・・・。
トランスフォームビュー、ツーステップビューなどは飛ばす。今はclient(ブラウザ)側でもMVCバリバリなコードを書くのでサーバがUI(HTML)を描画して返す時代ではない。
第15章 リモートファサード
ここで説明していた役割は今RESTful APIサーバなどに変わっていると思う。 なので流した。
第16章 オフライン並行性パターン
軽オフラインロックは楽観的オフラインロック、重オフラインロックは悲観的オフラインロックと読み替えること。
楽観的オフラインロックの仕組みとしてはバージョン番号(auto incrementな整数のイメージ)を使う。 タイムスタンプはシステムクロックが当てにならない、特に複数サーバの場合同期が保証できないので使わないほうがよい。 master-slave型のDBであればDB側に時間を挿入させることでタイムスタンプを使ってもよいかもしれない。
一貫性のない読み込みと楽観的オフラインロックで防ぐ方法、タイムスタンプを使えば楽だと思ったがウェブサーバとDBサーバの時間が完全に同期していることを保証するのは難しいのでこのアプローチはいまいち。
(意訳) checkCurrentメソッド - 今他の誰かがデータを更新しているかどうかをバージョンカラムの値などからチェックする
書かれている通り長大なトランザクションを処理しているとき、その開始直後に失敗することが確定しているケースがある。 そういったときにこの関数でそれを予め知ることができれば非常に時間のかかるが失敗することが確定している処理に無駄な時間を割かなくて済む。
読み書きロック
これは非常にいいアイデア。何かのときに使いたいツールとして覚えておこう。
16.3 粗粒度ロック
エンティティツリー(DDD本では集合体 - aggregateと呼ばれているっぽい?)単位でロックを設定するパターン。
16.4 暗黙ロック
過去に関わっていた某システムで最用紙していた方式。 ただ、あまり良い方式には思えなかった。結局の所程度の差はあれプログラマーはトランザクションを常に意識する必要があり、それを暗黙的にすることはあまりよさそうではない。usingパターンを利用して勝手に開放してくれるようにするのはいいと思う。
17 セッションステートパターン
クライアントセッションステートが現代のWebアプリケーションでは良いのではないかと思う。 サーバセッションステートもデータベースセッションステートもスケーラビリティに欠け、また純粋なHTTPの考えに反する。 クライアントのコミット前の情報はクライアントサイドで持つべきである。
第18章 ベースパターン
基本的に今まで参照してきたのでスキップできる。
終わったー
