PoEAAとか
ロイホにしけこみ読書。
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での継承モデリング
とか。
共通の語彙としてのパターン
うん、確かに便利かもねー。
