Row Data Gateway

An object that acts as a Gateway to a single record in a data source.
There is one instance per row.

【補】LaravelのEloquentはこれかしらね
メモリ上のオブジェクトにDBアクセスコードを埋め込むことの短所
- ビジネスロジック + DBアクセス = 複雑
- テストが遅い
- 複数のDBにアクセスする場合、SQLの小さな違いが鬱陶しい
  - 【補】DBMS間の互換性の話か
Row Data Gateway
- 行レコードと同じ構造のオブジェクト
- 普段遣いの言語の通常の機構でDBアクセスを隠蔽
  - メソッド生えてる
    - insert
    - update
    - delete
  - findは生えてない(後述)

How It Works

単一のレコードを模すオブジェクト
- 実表の1行とか
- 1フィールド1カラム
SQLの型と、メモリ上のオブジェクトの型との間で型変換
- 単純なもの
Transaction Scriptから呼び出すと良い感じ
どうやってレコードfindしてくるの？
- static method
  - ポリモーフィズムの恩恵に与れない
- Finderクラスを別途容易
  - 1テーブルに対して1Finder-1Row Data Gateway
Active Recordとどう違うの？
- ドメインロジックを持つのがActive Record
- Row Data GatewayはDBアクセスのみを請け負うべき
実表以外を隠蔽してもいい
- ビュー
- クエリ
更新の競合について
- 巻き戻り
  1. 同一行に対するインスタンスを複数作る
  2. それぞれでupdate()する
  3. 先にupdate()した更新内容が後のupdate()で上書きされてしまう
- updatableなビューでも同様のこと起きる
  - 【補】実表を更新したあと、ビューを更新してしまう or 逆
- どうすんの
  - 一般的な防止策はない
  - update()を生やさないという選択も
実装が冗長
- 【補】複数のテーブルについて、ほぼほぼ同じような実装
- Metadata Mappingして自動生成しようぜ

そもそもGatewayを使うか
Gatewayを使う場合、Row Data GatewayとTable Data Gatewayとどっち使うのか
ドメイン層とのかねあい
- Transaction Script
  - 一番の使いどころ
    1. DBアクセスをRow Data Gatewayにくくり出す
    2. スクリプト間でコピペされているロジックをRow Data Gatewayにくくりだす
    3. いつの間にかTransaction Script + Active Recordになる
- Domain Model
  - ロジックがシンプルならActive Record
  - ロジックが複雑ならData Mapper
  - Row Data Gatewayはまず使わない
Row Data GatewayとDBの構造とを揃えるか独立させるか
- 独立させると、DBの変更がドメインオブジェクトに影響を及ぼすのを防げる
  - DBのテーブル構造 <- 変更がありました
  - Row Data Gateway <- ここで吸収しました
  - ドメインオブジェクト <- 影響なし
- が、異なるデータ構造を3つ抱えることになる。多すぎ
- ので、著者はRow Data Gatewayの構造とDBのテーブル構造とを揃える派
Data MapperとRow Data Gatewayとの併用
- 全部手で書く場合は手間が増えるだけ
- Row Data Gatewayをメタデータから自動生成すると真価を発揮する
  - Data MapperはDBを意識せずデータ構造のマッピングに集中できる

コード略(pp.158-159)
ドメインオブジェクトがRow Data Gatewayを集約
- ドメインロジックは自分で持つ
- DBアクセスはRow Data Gatewayに委譲