ORM
Overview
ORM（Object-Relational Mapping）は、プログラム内のオブジェクトとリレーショナルデータベース内のデータを自動的にマッピングする技術です。これにより、SQLを直接書かずにデータベース操作が可能になります。
クエリビルダー
ORMでQuery Builderを使う場合、SQLクエリをプログラム的に構築できる。
Query Builderはもっとも低レベルのAPIとなり、SQLを生で生成するような役割を果たします。
SQLを手動で書く手間を省き、ORMを使うことでセキュリティ（SQLインジェクション対策）や保守性の向上が期待できる。
ORMデザインパターン
ORMではいくつかのデザインパターンがある。以下はTypeORMより。
TypeORM では、Active Record パターンと Data Mapper パターンの両方を使用できます。
Data Mapperパターン == Repositoryパターン
TypeORMリファレンス Data Mapperアプローチでは、すべてのクエリメソッドがリポジトリと呼ばれる個別のクラスに定義され、リポジトリを使用してオブジェクトを保存、削除、読み込みができます。 このアプローチにより、オブジェクトとデータベース間のロジックを分離し、テスト容易性と保守性が向上します。
Repositoryパターン 参考URL Repositoryパターンは、永続化を隠蔽するためのデザインパターンで、DAO（Data Access Object）パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。
ActiveRecord
Enterprise Application PatternsのひとつであるActive Recordパターンでは、1つのデータベーステーブルに対応するクラスが、各行をラップし、データベースアクセスとドメインロジックの両方をカプセル化します。 データベースのレコードをオブジェクトとして表現し、そのオブジェクトに対してCRUD操作を行うというものです。
• メリット: 単純なCRUDアプリケーションに適しており、手早く開発できる。 • デメリット: データベースのテーブルやビューの行をラップし、データベースへのアクセスをカプセル化し、そのデータにドメインロジックを追加するオブジェクトです。 ドメインオブジェクトにデータアクセスロジックを配置するイメージ。 ロジックとデータアクセスが密結合になってしまうためテストがしにくくなる（DB 接続が必要になる）
- メリット
- 単純なCRUDのWebアプリ開発には向いている
- デメリット
- 手続き型言語に近づいてしまう
- 単一責務違反になる
- テストしにくい
- ドメインロジックとデータアクセスが密結合してしまうため、テストが困難で、複雑なアプリケーションには不向き。
DataMapper
Enterprise Application Patternsのひとつ
オブジェクトとデータベースの間で、互いに独立した状態を保ちながらデータを移動させ、マッパー自体も独立させる。 DataMapperは、メモリ内（実行中プログラム）のオブジェクトをデータベースから分離するソフトウェアのレイヤー。
DataMapperを使用することで、メモリ内（実行中のプログラム）のオブジェクトはデータベースが存在することを知る必要はないので、データベーススキーマの知識も必要でなくなる
メリット ActiveRecordのデメリットを改善する デメリット 複雑性が増すので、ActiveRecordに比べると一時的なスピードが落ちる 単純なアプリに対してオーバースペックになる可能性がある
Repository
ドメインオブジェクトにアクセスするためのコレクションのようなインターフェースを使用して、ドメインとデータマッピング層の間を仲介する。 Repositoryはドメインとデータマッピングレイヤーの間を仲介し、メモリ内（実行中プログラム内）のドメインオブジェクトコレクションのように機能する。
概念的には、リポジトリはDBに保存されたオブジェクトのセットと、それらに対して実行される操作をカプセル化し、オブジェクト指向のビューを提供する。
Entityを効率的に永続化するためのオブジェクト DataMapperは単一のEntityを永続化するためのオブジェクト Repositoryは複数のEntityを永続化するためのオブジェクト