PoEAA ch12 Dependent Mapping
Dependent Mapping
Has one class perform the database mapping for a child class.
- 「他のオブジェクトのコンテキストでしか現れないオブジェクト」もある
- 例: アルバムに対するトラック
- トラックのload/saveには必ずアルバムのload/saveを伴う
- 例: アルバムに対するトラック
- 上記の例の場合、トラック他のテーブルから参照されないならば、O/Rマッピングを簡略化できる
- AlbumMapperがTrackのマッピングも担う
- このようなマッピングをDependent Mappingと呼ぶ
How It Works
- 言葉の定義
- dependent
- Track class
- owner
- Album class
- dependent
- 前提条件
- 各dependentはちょうど1つのownerをもつ
- O/Rマッピングが簡略化される
- ownerを読み込む時、同時にdependentsも読み込む
- それが高コストで避けたい場合はLazy Loadを仕込む
- dependent単体で読み込むことはない
- dependentはIdentity Fieldをもたない
- Identity Mapへの登録をおこなわない
- dependent用のFinderもない
- dependentがさらに下位のdependentを持つ場合は?
- 最上位のownerがマッピングの責務を負う
- dependentのテーブルの主キーは、ownerの主キーを含めた複合主キーにするとよい
- ownerと関連のない別のテーブルから参照されることを防ぐ
- 「各dependentはちょうど1つのownerをもつ」という仮定を守る
- ownerと関連のない別のテーブルから参照されることを防ぐ
- UML的の「コンポジション」で表されるような関連
- 【補】dependentは他のオブジェクトからは参照されず、ownerとライフサイクルを共にする
- Dependent Mappingである場合、更新はdelete/insertで安全に行える
- 他のテーブルから参照されないため
- シンプル
- dependentの変更はownerに通知し、印をつける必要がある
When to Use It
- 前提条件
- dependentで大きなオブジェクトグラフを構成するのは避けたほうがいい
- オブジェクトグラフ外からは参照できない
- ので、owner経由でルックアップしなければならない
- 深いとつらい
- Unit of Work使用時はDependent Mappingの利用は非推奨
- delete/insertにしたところで単純にならない
- Unit of Workがオブジェクトの更新を追跡しているため
- ownerのないdependentレコードが生じてしまったりする
- Unit of Workはdependentを追跡しないため
- delete/insertにしたところで単純にならない