読者です 読者をやめる 読者になる 読者になる

Table Data Gateway(1)

Data Source Architectural Patterns

Table Data Gateway

  • ひとつのインスタンスがテーブルの全ての行を制御する
  • 一つのテーブルやビューに対するselectやupdate, deleteなどをすべて(1つのクラスに)集約する
How it works
  • selectに対応するfindメソッドを条件により複数作る
  • update, delete, insertといった操作に関するメソッドも作る
  • 通常は各メソッドはステートレス(状態を持たない)
  • 問題はどのようにしてクエリの結果を返すか。マップのような構造に詰めて返すこともできるが、(データベースの項目とマップに格納されるキーとの関係は)コンパイルなどでもチェックできず、誤りやすい。Data Transfer Objectパターンを使うのがよい選択肢となる。SQLの結果としてのRecord Setをそのまま返すこともできるが、データベースに特化してしまい、インターフェースをファイルなど他のものに置き換えにくくなるかもしれない。
  • 実際のデータベースのテーブルごとに(=正規化したあとなど、RDBとして格納に適した形で)つくるのではなく、ビューごとに(=実際に使用する形で)、Table Data Gatewayを作ることで、データベースとの結合性を低くすることができる
  • ビューベースのTable Data Gatewayにupdateなどの振る舞いをもたせるときは、その元になっている実際のテーブルに対する更新を行う。それができるのなら、Table Data Gatewayはよいテクニックとなる。
  • Domain Modelを使用している場合は、Table Data Gatewayが適切なDomain Objectを返してくれる。しかし、両方向に依存性がある(=変更があれば、両方に影響する)。