Eloquent が動くコードになるまでの近道は Active Record、でもその便利さの裏でモデルは簡単にメタボ化します。遠回りに見える Data Mapper は細かく責務を分けるぶん足取りが重いけれど、あとでリファクタが来ても膝を壊しません。どちらを選ぶか――まずは地図を広げて道標を読み解くところから始めましょう。
Active Record と Data Mapper を 3 分で見分ける
判断軸は三つです。「誰が SQL を握る？」「モデルは太る？」「テストは書きやすい？」──この三点で流派は一瞬で判別できます。
💡この記事でやること
- Active Record と Data Mapper を 絵とコード でサクッと比較 🖼️
- Eloquent がどっち側か、Doctrine が何者かを腹に落とす 🤔
- モデルが太ったらどこへ逃がすか、最初のヒントを持ち帰る 🏃♂️
ORM ってそもそも何？
💡 ざっくり一言: DB の行とクラスのインスタンスを “通訳” してくれる仕組み。
たとえば・・・
- テーブル ↔ モデルクラス
- カラム ↔ プロパティ
- レコード ↔ インスタンス
「SQL を書かずに済む魔法」だけで終わらせると、どこまでをモデルに書く？ で必ず迷う。なので次章へ。
大流派：Active Record vs Data Mapper
魔法の杖で殴るか、工具箱で組むか、すぐ動くか、後で伸びるかの境界線を、決めるための判断軸。
| 観点 | Active Record (Eloquent) | Data Mapper (Doctrine) |
|---|---|---|
| 責務 | モデルが自分で DB を叩く | DB とのやり取りは Repository / EntityManager |
| 初期学習コスト | 低 – 魔法みたい | 高 – 現実と向き合う |
| よくある罠 | Fat Model（太りすぎ） | クラス爆増で頭がパンク |
ボクはEloquentが好きだな〜。だけどフレームワーク毎変えなきゃいけなくなったら大変かも〜。
コードで見ると一瞬
// --- Eloquent (Active Record)
$user = User::create(['name' => 'Yuzu']);
$user->posts()->create(['title' => 'Hi']);// --- Doctrine (Data Mapper)
$user = new User('Yuzu');
$em->persist($user);
$em->flush();
「モデルが SQL まで面倒見る派」か「SQL は外部スタッフに丸投げ派」かの違いなのかな〜。
モデルの中に何を書けばいい？
Eloquent を「ただの属性箱」にすると、コントローラが条件だらけで肥満一直線。
class User extends Model
{
// 属性
protected $fillable = ['name','email','status'];
// 関係
public function posts() {
return $this->hasMany(Post::class);
}
// スコープ
public function scopeActive($q) {
return $q->where('status','active');
}
// ビジネスロジック
public function deactivate() {
$this->update(['status'=>'inactive']);
}
}属性・関係・スコープ・ビジネスロジック、モデルに入れるのはここまでにしておこうね〜。
じゃあいつ Data Mapper にする？
ここから先は「モデルが太る・テストが辛い・DB が散らばる」三大ストレスへの避難誘導口。 ひとつでも刺さったら、下のチェックリストで即セルフ診断してみてください。
セルフ診断
- モデルが 1,000 行超えて読めない 🤯
- テスト用に DB 切り替えたいけどクエリがべったり 🧪
- マイクロサービスで DB が分散しまくった 🌐
- Laravelに依存したくない 💀 👉️ 移行可能だけど面倒
こんな時は Repository か Doctrine を検討するとハマりにくい。
FAQ（よくある壁打ち）
-
Eloquentで「N+1問題」って何？
-
リレーションを定義せず、ループ内で都度DBアクセスが発生し爆速で遅くなる現象。
→with()やload()で事前取得すると吉。
-
「スコープ」って何のために使う？
-
よく使う絞り込み条件をまとめて、コントローラをスッキリさせる。
例：User::active()->get()←scopeActiveでModelに実装
-
ORMって、Eloquentと何が違う？
-
ORMは仕組み全体、EloquentはLaravel流ORMの一実装。
-
Doctrineみたいな「DataMapper型」と何が違う？
-
DataMapperはモデル＝ただの箱。DB操作は外に任せる。
-
Eloquent使いこなすと実装が良くなるの？
-
「どこに何を書くか」を意識することが重要。Eloquentを意識すれば少なくともFacControllerは防げる。ほかも追求していけばきっと良くなる。
-
結局、「Eloquentを本当に理解してる」と言える瞬間は？
-
Eloquentの役割と限界を実装で選び取るだけでなく、それがなぜその選択が最適なのかをシステム構造や要件から逆算して根拠を持って決めているとき。
-
何故Doctrineだと移行が楽？
-
ComposerでDoctrineさえ入れれば、Repositoryがそのまま流用可能できるから。👉️ 初心者でも超簡単！Composerのインストールと設定方法（Windows・Mac対応）
まとめ — 理解してる と言える瞬間
選択の理由を語れたら合格。
- Active Record / Data Mapper を “腹で” 選び分ける
- モデルが太ったらどこへ逃がすか
- サービス層に逃がす？（初心者向け）
- Repositoryを考える？（中級者向け）
- いっそのことLaravelを深堀りしてみる？ (…)
- 誰かに質問されたら 「この設計にした理由」を 3 行で説明できる
コメントを残す