WR blog

ロイホにしけこみ読書。

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での継承モデリング

とか。

共通の語彙としてのパターン

うん、確かに便利かもねー。

May 6th, 2005 | Category: Book, Java, ObjectModeling, RelationalModeling, WebObjects | Leave a comment