ここからは、ビジネスロジックをどのように書くかとは別の視点、データソースのアーキテクチャに関するパターンを扱います。
ビジネスロジックの記述、とくに Domain Model においては、データ(あるいはオブジェクト)の扱いと取得/同期方法の関心を、できるだけ分離するのが健全です。ほとんどのデータベース操作は、単純で冗長な SQL の組み立てになってきます。データが出入りするインターフェースを、ビジネスロジックから見たゲートウェイとするのです。
Table Data Gateway は、特定のテーブルとの単純な入出力を担います。責務範囲がひとつのテーブルに閉じるため、Table Module との依存関係がシンプルになります。データの操作は find(id) や insert(data) といったメソッドで担います。
データの形式に、固有のデータ型を設けるか、汎用的なレコードセット型のままにするかについては、どちらでもかまいません。データベースの具体的操作を隠蔽することにのみ着目してください。
Table Data Gateway だけで十分な場合、このオブジェクトは update(id, data) と delete(id) を持つこともあります。が、そうした、対応する行が明らかな更新や削除の操作は、Row Data Gateway に担わせることもできます。
Row Data Gateway は対応する行の主キーを知っており、ビジネスロジックで扱うデータを参照します (データ側に主キー値を持つこともありますが、わかりやすさのため、図ではゲートウェイに id 属性を持たせています)。改めてメソッド引数を取ることなく、この既知の知識を使って操作用の SQL を構築します。対応する行以外への操作を行わないものとすることで、責務範囲が明確になり、扱いやすくなります。
Table Data Gateway のインスタンス数は、テーブルの数と一致します。Row Data Gateway のインスタンス数は、取得された行の数と一致します。Row Data Gateway の生成の知識を隠蔽するために、Table Data Gateway の find メソッドを Row Data Gateway のファクトリとすることも可能です。