🎯 什麼情境該想到我
當你要設計「物件如何對應到資料庫」，或在不同 ORM 風格間抉擇、遇到 ORM 效能問題時。
⚙️ 怎麼用（認識底層模式）
- Active Record：物件自己包含資料庫存取邏輯（
user.save()）。簡單、快速，適合邏輯不複雜的 CRUD（Rails、Eloquent）。 - Data Mapper：物件與資料庫完全分離，由 Mapper 負責搬運。乾淨、可測、領域物件不依賴 DB，適合複雜領域（Hibernate、Prisma、TypeORM 的 mapper 風格）。
- Unit of Work：一次交易內追蹤所有變更，最後統一提交/回滾 → 減少 DB 往返、保證一致。
- Identity Map：同一物件一次請求只載入一次，避免重複查詢與不一致。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- ORM 隱藏了 SQL，容易踩 N+1 查詢與意外的大量載入；效能敏感處要看實際 SQL（呼應 工具-交易與隔離等級）。
🔗 相關工具
- 工具-領域邏輯組織模式 —— 姊妹題，先決定業務邏輯放哪，才知道該配哪種 ORM 風格
- 工具-資料結構的選擇 —— 效能面的延伸，ORM 慢常常是取回來之後用錯結構造成的
- 工具-交易與隔離等級 —— ORM 藏起來但你逃不掉的東西，工作單元與併發控制最終還是交易問題