Data Mapper で、とりあえずは Chapter 10. の Data Source Architectural Patterns はおわり。
オブジェクト指向言語におけるデータの表現と、RDBMS 上のデータの表現は本質的にインピーダンスアンマッチが発生します。 一方は継承等の技巧が使える一方、RDBMS ではそれを使うのが難しい。
- O/Rマッピングツールに対する誤解をときたい - give IT a try
- http://otndnld.oracle.co.jp/columns/arai-semi/data_access/2/#o_r
こういうところは、アーキテクチャとして解決していかないといけない、ということで、Data Mapper が登場します。 Data Mapper は、プログラム実装上の"オブジェクト"を DB 上のデータから切り離すためのレイヤとして機能します。この層の存在によって、開発者は SQL や DB 上のテーブル構造を意識せずに、ドメインロジックを構築していけるようになります。はい。
Finder
ぼくは Mapper と聞いて、DB のレコードの情報を実装上のオブジェクトに変換する Converter をイメージしていましたが、ここで述べられている Data Mapper はそれに留まる概念ではないようです。 例えば、ロジックのレイヤが DB からデータを取得するにあたり、その「情報取得の要求」は Data Mapper に送られます。言い換えれば、Data Mapper は DB に問い合わせてデータを取得するという Finder の役割を担います。よくよく考えてみれば、Data Mapper はロジックと DB の中間のレイヤに位置付けられるので当然ですね。
Data Mapper を実装する上での課題
- ロジック層に Finder とかを意識させないための技巧として遅延ロードがあるけど、遅延ロードを実装するのにそれだけの価値があるか
- Hibernate
とかはこのあたりを結構やってくれるけど、ぼくはあの動作が分かりにくくてスゴく嫌いだった
- Hibernate
- Data Mapper の配置
- Data Mapper はドメインロジックと密に結合することになるので、ドメインロジックにいくつかのメソッド実装を要求する。このようなメソッドを public とするか、それともパッケージプライベートにするか。
- public にする場合、他のロジッククラスに対して、「何このメソッド」というようなメソッドが公開されることになる
- パッケージプライベートにする場合、Data Mapper とドメインロジックは同一パッケージに配置されることになるので、ドメインロジックを使用する他のロジック/実装は Data Mapper の存在を意識できてしまう
