データソースのアーキテクチャ

データソースのアーキテクチャについて学んだことメモ。

TableDataGateway

• インスタンスがテーブル内のすべての行を操作する。
• SQLはこのインスタンス内に閉じる。
• https://bliki-ja.github.io/pofeaa/TableDataGateway/

RowDataGateWay

• 1クラス=1テーブル、1インスタンス=1レコードに対応する。
• CRUDの操作を行うのみで、ビジネスロジックは載せない。
  • 要はActiveRecoredからビジネスロジックを差し引いたもの。
• https://bliki-ja.github.io/pofeaa/RowDataGateway/

ActiveRecord

• 1クラス=1テーブル、1インスタンス=1レコードに対応する。
• CRUDの操作だけでなく、ビジネスロジックを実装して使う。
• レコードとビジネスロジックの結びつきが強い場合は使いやすい。
  • どのオブジェクトに実装すべきメソッドかわからなくなったときは、データモデリングに不備がある可能性がある。
  • たとえば、purchase の実装の場合
    • user.purchase でも、 product.purchased でもなく、purchase_event.create で表現できる。
    • purchase に伴う各種処理は、 create のコールバックで実装すればよい。
• 単一責任の原則には反している。
  • ビジネスロジックとデータ操作を1つのオブジェクトに詰め込むため。
  • データソースを変更したい(たとえばRDBからRedisに変えるなど)場合、影響がビジネスロジックまで及んで修正が困難になる可能性はある。
• https://bliki-ja.github.io/pofeaa/ActiveRecord/

DataMapper

• メモリ内のオブジェクトとデータベースのマッピングを行う。
  • 1オブジェクトに対して複数のテーブルをマッピングするケースもある。
• オブジェクトとデータベースの構造が1対1対応していない場合に使いやすい。
  • たとえば既存のデータベースの上にアプリケーションを構築する場合など。
• メモリ内のオブジェクトは、データソースの実態を気にしなくてよくなる。
  • データソースの変更を行ってもビジネスロジックに影響を及ぼすことはない。
    • DataMapperがオブジェクトに提供しているインターフェースを変更しなければ。
• https://bliki-ja.github.io/pofeaa/DataMapper/