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アクセスのみを請け負うべき
-
実表以外を隠蔽してもいい
- ビュー
- クエリ
-
更新の競合について
-
巻き戻り
- 同一行に対するインスタンスを複数作る
- それぞれでupdate()する
- 先にupdate()した更新内容が後のupdate()で上書きされてしまう
-
updatableなビューでも同様のこと起きる
- 【補】実表を更新したあと、ビューを更新してしまう or 逆
-
どうすんの
- 一般的な防止策はない
- update()を生やさないという選択も
-
-
実装が冗長
- 【補】複数のテーブルについて、ほぼほぼ同じような実装
- Metadata Mappingして自動生成しようぜ
When to Use It
- そもそもGatewayを使うか
- Gatewayを使う場合、Row Data GatewayとTable Data Gatewayとどっち使うのか
-
ドメイン層とのかねあい
-
Transaction Script
-
一番の使いどころ
- DBアクセスをRow Data Gatewayにくくり出す
- スクリプト間でコピペされているロジックをRow Data Gatewayにくくりだす
- いつの間にか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を意識せずデータ構造のマッピングに集中できる
Example: A Person Record (Java)
- 略
Example: A Data Holder For a Domain Object (Java)
- コード略(pp.158-159)
-
ドメインオブジェクトがRow Data Gatewayを集約
- ドメインロジックは自分で持つ
- DBアクセスはRow Data Gatewayに委譲
英語
-
crux
- 核心