ロイホにしけこみ読書。
Essential XML・・・うーむどうなんだろう。ちょっと必要以上にわかりにくく書いてないか？この本。
訳が良くないというのもあるけど・・・（シリアライズを「順序化」って、あーた・・・。せめて「直列化」で頼む。）
インフォセットの語りもなんだか抽象的でよーわからんし、SAX、DOMのあたりも構成が練れていない感じ。
PoEAA読書会に向けて、2部のパターン、O-Rマッピングあたりをさらりと読む。
1部の概論はイマイチしっくり来なかったが、2部はまぁまぁな気がする。
各パターンの説明の中で、未説明のパターンに言及するあたりがなんだかなーだけど、
各パターンの概要が頭に入ってきてパターン間の関係を頭の中で整理することができると、
比較的すんなり読めた。
ただ、ファウラーのコメントが散文的で踏み込みが甘いので、若干フラストレーションがたまるなぁ。
もう少し、具体的なコメントがほしいところではある。
現在は様々なフレームワークが出回っているわけだから、それらに触れるような切り口もありなのでは？と思ったりした。
### EOFとPoEAA ###
パターンの本来的な役割は、共通の語彙・概念の形成であると理解している。
というわけで、PoEAAの語彙・概念を利用してEOFを表現する。（乱文すぎるので、たぶん、あとで書き直す）
### ドメインロジックパターン ###
ドメインロジック(=ビジネスロジック) の割り当ての方針は、基本的に「ドメインモデルパターン」が推奨される。
もちろん、画面にビジネスロジックを埋め込むような実装・設計も可能ではあるけれども。
物理的にも、「ドメインモデル」を実装したオブジェクト群をパッケージ化・フレームワーク化して、様々なアプリケーション形態（WOFと呼ばれるリッチなWebアプリケーションフレームワークを使用したWebアプリケーション、DirectToWebと呼ばれるルールベースのUI定義ベースのWebアプリケーション、Javaクライアントなどなど）で、それらを共用することが(それなりに)一般的であるようだ。
### データソースのアーキテクチャに関するパターン
データソースとオブジェクトの変換は、オブジェクトグラフとリレーショナルモデルの変換という形で実行される。
であるので、「データマッパーパターン」になるのかな？
オブジェクトとリレーショナルの対応は、物理的には*.eomodelファイル群、論理的にはEOModelGroup、EOModelなどのメタモデルクラス群で管理される。（「メタデータマッピングパターン」に相当）
### オブジェクトリレーショナル振る舞いパターン ###
基本的に、「ユニット・オブ・ワーク パターン」。
EOEditingContextと呼ばれる、オブジェクトグラフの編集用ブール、SandBox的なオブジェクトが存在しており、これがオブジェクトグラフの編集状態を管理する。編集をコミットしたタイミングで、オブジェクトの編集処理が、SQLクエリに変換される（「データ・マッパー パターン」）。この際、デフォルトでオプティミスティックロック戦略が使用される・・・ことになっている。(苦笑&謎めき)
EOEditingContextの寿命とWeb層のSessionの寿命がシンクしている点がなかなかいい感じではある。
(超私見)
#### 一意マッピング ####
異なる2つの世界、RDBMSとオブジェクトの中で、一意性をどのように、どのレベルで確保するか？という戦略。
EOFは一意性に関しては、2種類の一意性管理をもつ。
「ユニット・オブ・ワーク」単位の一意性と、データベース群レベルの一意性であり、EOGlobalIDなるクラスを用いることで一意性管理を実行する。EOGlobalIDは「データソース×テーブル×プライマリキーの組み合わせ」と考えてよい。文字通り、複数データソース内で、グローバルに一意である。
1つの編集用領域(EOEditingContext)には、同じEOGlobalIDのオブジェクトは1つしか読み込まれない。
ただし、複数ユーザーが編集中である場合など、複数の編集用領域が存在する場合、同じEOGlobaIDのオブジェクトが複数存在する。(当たり前！)
ただし、下位のデータ管理レイヤがそれぞれのオブジェクトをトラッキングしており、あるオブジェクトが編集された場合、同じEOGlobalIDを持つ別のオブジェクトに変更を伝播させたり、しなかったりする。
#### レイジーロード ####
レイジーロードはfaultingと呼ばれる機構でサポートされる。
関連の先にぶら下がっているオブジェクトは、必要に応じてRDBMSから読み込まれる。
（キャッシュと絡むと何がなんだか・・・ということになりそうな気もしないでもない。）
### 構造パターン
#### 一意フィールド ####
基本的にPKはoid的扱いが基本。オブジェクトのライフサイクルでPKの値を変更することは想定外!(だったと思う)
#### 外部キーマッピング ####
外部キーというか、RDBのリレーションシップは、デフォルトでは(オブジェクトグラフにおける)双方向の参照の持ち合いに変換される。toOneは単なる参照に、toManyはコレクションに格納された参照になる。
アプリケーションは(基本的に)上記の仕組みを理解する必要が無い。参照の管理のみをキチンとやればよい。
(「データ・マッパー」の枠組みの中で自動的に行われる)
#### 関連テーブル・マッピング ####
忘れた・・・
#### 依存マッピング ####
「依存」という概念は無かったはず。
#### 組込バリュー ####
メタデータの枠組みの中で、カラム→オブジェクト、オブジェクト→カラムのマッピング戦略を定義可能。
ファクトリメソッドと、シリアライズメソッドを定義しておけばよい(←用語は怪しい)
#### シリアライズLOB ####
上記と同様の考えて実現可能（な、はず・・・）
#### 各種継承 ####
用語は違うが、3つの継承をサポートする。
EOFの世界では、
* 垂直マッピング継承
* 水平マッピング継承
* シングルテーブル継承
と呼ぶ。(つーか、こちらの用語の方が一般的?)
### 関連資料 ###
自作のWOMeeting – WOWiki用の資料なぞ。
* EOModeling Techniques from Practical WebObjects
* Managing the Object Graph from Practical WebObjects
* WebObejects/EOFでの継承モデリング
とか。
### 共通の語彙としてのパターン ###
うん、確かに便利かもねー。
Leave a Reply