理系学生日記

おまえはいつまで学生気分なのか

PoEAA: Data Mapper

Data Mapper で、とりあえずは Chapter 10. の Data Source Architectural Patterns はおわり。

オブジェクト指向言語におけるデータの表現と、RDBMS 上のデータの表現は本質的にインピーダンスアンマッチが発生します。 一方は継承等の技巧が使える一方、RDBMS ではそれを使うのが難しい。

こういうところは、アーキテクチャとして解決していかないといけない、ということで、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 とかはこのあたりを結構やってくれるけど、ぼくはあの動作が分かりにくくてスゴく嫌いだった
  • Data Mapper の配置
    • Data Mapper はドメインロジックと密に結合することになるので、ドメインロジックにいくつかのメソッド実装を要求する。このようなメソッドを public とするか、それともパッケージプライベートにするか。
    • public にする場合、他のロジッククラスに対して、「何このメソッド」というようなメソッドが公開されることになる
    • パッケージプライベートにする場合、Data Mapper とドメインロジックは同一パッケージに配置されることになるので、ドメインロジックを使用する他のロジック/実装は Data Mapper の存在を意識できてしまう