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はちょうど1つのownerをもつ
-
O/Rマッピングが簡略化される
-
Row Data Gateway, Active Record
- dependent: 何もしない
- owner: dependentのマッピングも行う
-
Data Mapper
- dependent: 対応するMapperなし
- owner: dependentのマッピングも行う
-
Table Data Gateway
- dependent: 対応するGatewayクラスなし
- owner: dependentのマッピングも行う
-
-
ownerを読み込む時、同時にdependentsも読み込む
- それが高コストで避けたい場合はLazy Loadを仕込む
-
dependent単体で読み込むことはない
- dependentはIdentity Fieldをもたない
- Identity Mapへの登録をおこなわない
- dependent用のFinderもない
-
dependentがさらに下位のdependentを持つ場合は?
- 最上位のownerがマッピングの責務を負う
-
dependentのテーブルの主キーは、ownerの主キーを含めた複合主キーにするとよい
-
ownerと関連のない別のテーブルから参照されることを防ぐ
- 「各dependentはちょうど1つのownerをもつ」という仮定を守る
-
-
UML的の「コンポジション」で表されるような関連
- 【補】dependentは他のオブジェクトからは参照されず、ownerとライフサイクルを共にする
-
Dependent Mappingである場合、更新はdelete/insertで安全に行える
- 他のテーブルから参照されないため
- シンプル
-
dependentの変更はownerに通知し、印をつける必要がある
- ownerに、dependentsの更新をRDBに書き戻してもらうため
-
dependentをimmutableにするとシンプルにできる
- 変更時は、dependentを取り除いて新しいオブジェクトをぶら下げる
- 【補】参照が変わっていれば更新対象
-
が、メモリ上オブジェクトの取り回しは大変になる
- 理屈上はデータマッピングの都合がドメインオブジェクトに影響を与えるべきではない
- が、たまには実践上妥協することもある
When to Use It
-
前提条件
- dependentはちょうど1つのownerをもつ
- dependentは、owner以外から参照されない
- 【補】UMLでコンポジションと呼ばれるような関連
-
dependentで大きなオブジェクトグラフを構成するのは避けたほうがいい
- オブジェクトグラフ外からは参照できない
- ので、owner経由でルックアップしなければならない
- 深いとつらい
-
Unit of Work使用時はDependent Mappingの利用は非推奨
-
delete/insertにしたところで単純にならない
- Unit of Workがオブジェクトの更新を追跡しているため
-
ownerのないdependentレコードが生じてしまったりする
- Unit of Workはdependentを追跡しないため
-