Eloquent 不只是 CRUD！資深工程師揭秘 Laravel ORM 進階戰術與效能黑魔法

嘿，我是浪花科技的 Eric。在工程師的世界裡，Laravel 的 Eloquent ORM 就像一把瑞士刀，幾乎每個專案都會看到它的身影。它優雅的語法讓我們能用物件導向的方式操作資料庫，告別手寫 SQL 的惡夢。但說實話，我看到太多開發者只停留在 find()、save()、delete() 這些基本操作，就像買了台法拉利卻只用來買菜，實在太可惜了！

Eloquent 的強大遠不止於此。它隱藏了許多進階功能和「黑魔法」，能讓你的程式碼更乾淨、更有效率，也能幫你避開那些會讓網站半夜崩潰的效能地雷。今天，我就以一個資深工程師的小囉嗦，帶你深入這份 Laravel Eloquent ORM 完整指南的進階篇，從模型屬性、複雜關係，一路談到效能優化的終極殺手鐧。準備好了嗎？讓我們一起從「會用」Eloquent 晉升到「精通」Eloquent！

魔鬼藏在細節裡：善用 Accessors, Mutators 與 Attribute Casting

很多人覺得 Model 就只是對應到資料庫的一張表，其實不然。一個設計良好的 Model 應該是資料的守門人，負責資料的格式化、驗證與轉換。而 Accessors（取用器）、Mutators（修改器）與 Attribute Casting（屬性轉換）就是你最好的工具，它們不是語法糖，而是維持程式碼整潔與資料一致性的重要武器。

Accessors & Mutators：資料進出的自動化妝師

簡單來說：

• Accessors (取用器): 在你從 Model 取出資料時自動進行處理。例如，將 first_name 和 last_name 組合起來變成 full_name。
• Mutators (修改器): 在你存入資料到 Model 時自動進行處理。最經典的例子就是儲存密碼前自動進行雜湊加密。

這就像是給資料請了個自動化妝師，出門（取出）前打扮一下，回家（存入）前先卸妝整理。讓我們看個實際例子，假設我們有個 User Model：

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Facades\Hash;

class User extends Model
{
    /**
     * 取得使用者的全名。
     *
     * @return string
     */
    public function getFullNameAttribute()
    {
        return "{$this->first_name} {$this->last_name}";
    }

    /**
     * 設定使用者的密碼，自動加密。
     *
     * @param  string  $value
     * @return void
     */
    public function setPasswordAttribute($value)
    {
        $this->attributes['password'] = Hash::make($value);
    }
}

定義好之後，你就可以這樣用：

// Mutator in action
$user = new User;
$user->first_name = 'Eric';
$user->last_name = 'Lee';
$user->password = 'super-secret-password'; // 會自動被 Hash::make()
$user->save();

// Accessor in action
echo $user->full_name; // 輸出 'Eric Lee'

是不是很優雅？Controller 裡的程式碼完全不需要知道密碼加密的細節，所有邏輯都封裝在 Model 裡了。

Attribute Casting：讓 Laravel 自動幫你轉換資料型別

有時候，我們只是想做簡單的資料型別轉換，例如把資料庫裡的 `0` 或 `1` 轉成 `true` 或 `false`，或是把 JSON 字串轉成陣列。這時候用 Mutator 就有點殺雞用牛刀了。Laravel 提供了更簡潔的方式：Attribute Casting。

你只需要在 Model 裡定義一個 $casts 屬性：

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Post extends Model
{
    /**
     * The attributes that should be cast.
     *
     * @var array
     */
    protected $casts = [
        'is_published' => 'boolean',
        'options' => 'array', // or 'json'
        'published_at' => 'datetime',
    ];
}

設定好之後，當你存取這些屬性時，Laravel 會自動幫你做好轉換。例如，當你存取 $post->is_published 時，你會得到一個布林值 `true` 或 `false`，而不是字串 `’1’` 或 `’0’`。當你存取 $post->options 時，你會得到一個 PHP 陣列，而不是一個 JSON 字串。相信我，這能省下你無數次的 `json_decode` 和型別判斷。

關係的藝術：不只是 hasMany，你聽過多態 (Polymorphic) 嗎？

Eloquent 的精髓在於它的關聯性定義。hasOne, hasMany, belongsTo 這些大家都很熟了。但當應用程式的結構變得複雜時，你需要更強大的武器。多態關聯 (Polymorphic Relations) 就是其中之一。

多態關係 (Polymorphic Relations)：一對多的終極進化

想像一個情境：你的網站上有「文章 (Posts)」和「影片 (Videos)」，而這兩者都可以被「留言 (Comments)」。如果按照傳統做法，你可能得在 `comments` 資料表上建立 `post_id` 和 `video_id` 兩個外鍵欄位，而且其中一個永遠是 NULL。這很不優雅，而且未來如果新增了「圖片 (Images)」也能留言，你又要去改資料庫結構。

多態關聯就是為了解決這個問題而生的。它讓一個 Model 可以屬於多種不同的其他 Model，只需要兩個欄位：

• commentable_id：儲存對應的 Model ID (例如 Post ID 或 Video ID)。
• commentable_type：儲存對應的 Model 類別名稱 (例如 `App\Models\Post`)。

設定方法如下：

Comment Model:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Comment extends Model
{
    /**
     * Get the parent commentable model (post or video).
     */
    public function commentable()
    {
        return $this->morphTo();
    }
}

Post & Video Models:

<?php
// In Post.php and Video.php

use Illuminate\Database\Eloquent\Model;

class Post extends Model
{
    /**
     * Get all of the post's comments.
     */
    public function comments()
    {
        return $this->morphMany(Comment::class, 'commentable');
    }
}

這樣設定好之後，不論是文章還是影片，你都可以用一樣的方式來操作留言：

$post = Post::find(1);
foreach ($post->comments as $comment) {
    // ...
}

$video = Video::find(1);
foreach ($video->comments as $comment) {
    // ...
}

從留言反向找到它的主人也很簡單：$comment->commentable。這就是多態的威力，讓你的資料庫結構和程式碼都更有彈性。

效能殺手現形記：你踩過 N+1 查詢的坑嗎？

好，接下來要講的，是每個 Laravel 新手幾乎都踩過的坑，也是區分資深與否的關鍵點：N+1 查詢問題。這個問題在開發環境通常不明顯，因為資料量小，但一上到正式環境，它就會變成拖垮你網站效能的頭號殺手。

什麼是 N+1 問題？一個血淋淋的例子

想像一下，你要顯示一個文章列表，並且在每篇文章旁邊顯示作者的姓名。你的程式碼可能是這樣寫的：

// Controller
$posts = Post::all(); // 這裡執行了 1 次查詢

// Blade View
@foreach ($posts as $post)
  <li>
    {{ $post->title }} by {{ $post->author->name }} <-- 每次迴圈都執行 1 次查詢
  </li>
@endforeach

看起來沒問題對吧？但魔鬼就在 `{{ $post->author->name }}` 這裡。因為 Eloquent 預設是「延遲載入 (Lazy Loading)」，當你在迴圈中第一次存取 `$post->author` 時，它會為了那一篇文章，再去資料庫撈一次作者的資料。

所以，如果你有 100 篇文章，這段程式碼總共會執行 1 (撈所有文章) + 100 (每次迴圈撈作者) = 101 次資料庫查詢！這就是 N+1 問題，它會隨著資料量增加而呈線性增長，非常恐怖。

救贖之道：預載入 (Eager Loading) 的神威

解決 N+1 問題的方法非常簡單，就是使用「預載入 (Eager Loading)」。你只需要在查詢時告訴 Eloquent：「嘿，幫我把文章撈出來的同時，順便把相關的作者資料也一次撈回來！」

只要一個 `with()` 方法就能搞定：

// Controller
$posts = Post::with('author')->get(); // 關鍵就在這裡！

這樣修改之後，Eloquent 只會執行 **2** 次查詢：

1. SELECT * FROM posts
2. SELECT * FROM authors WHERE id IN (1, 2, 3, ...)

它先把所有文章撈出來，然後收集所有文章的 `author_id`，再一次性地把所有需要的作者資料撈回來，並在記憶體中進行配對。不論你有 10 篇還是 1000 篇文章，永遠都只需要 2 次查詢。效能差異是天壤之別！我強烈建議大家安裝 Laravel Debugbar 這類工具，它能清楚地顯示每個頁面執行了多少次查詢，幫你揪出 N+1 問題。

Eloquent vs. Query Builder：何時該放下魔法，回歸樸實？

Eloquent 如此強大，那是不是我們就完全不需要原生的 Query Builder (`DB::table(…)`) 了呢？當然不是。身為一個資深的工程師，你需要知道每種工具的適用場景，而不是一招半式闖江湖。

效能與便利性的拔河

Eloquent 的便利性來自於它的「物件填充 (Hydration)」過程，它會把查詢結果轉換成一個個完整的 Model 物件，這包含了很多額外的處理，是有成本的。當你需要處理非常大量的資料，或是進行複雜的資料彙整報表時，Eloquent 的這層抽象可能就會成為效能瓶頸。

Query Builder 的最佳戰場

在以下幾種情況，我會毫不猶豫地選擇 Query Builder：

• 大量資料的更新或插入： 當你需要一次更新上萬筆資料的某個欄位時，使用 `DB::table(‘users’)->where(…)->update(…)` 會比撈出所有 Model 物件再逐一儲存快上好幾個數量級。
• 複雜的 Join 和 Group By： Eloquent 也能處理 Join，但語法相對囉嗦。對於需要多個複雜 Join 和 Aggregation (如 `COUNT`, `SUM`) 的報表查詢，Query Builder 的語法更直觀、更接近原生 SQL。
• 效能極端敏感的查詢： 如果某個查詢是網站的核心瓶頸，直接使用 Query Builder 可以跳過 Model 的物件填充過程，榨出最後一滴效能。

記住，Eloquent 和 Query Builder 不是敵人，而是可以協同作戰的夥伴。了解它們各自的優缺點，並在對的時機使用對的工具，這才是大師之道。

總結：成為一位真正的 Eloquent 大師

今天我們一起探索了 Laravel Eloquent ORM 完整指南中的幾個進階主題。從善用 Accessors/Mutators 讓 Model 更智慧，到駕馭多態關聯處理複雜的資料結構，再到破解 N+1 這個效能殺手，最後權衡 Eloquent 與 Query Builder 的使用時機。

掌握這些技巧，不僅能讓你的程式碼品質提升一個檔次，更能讓你在面對複雜需求和效能挑戰時游刃有餘。Eloquent 是一把強大的雙面刃，用得好，它是開發效率的加速器；用得不好，它就是效能災難的製造機。希望今天的分享，能幫助你成為那位能駕馭神兵的真正大師。

延伸閱讀

• 肥 Controller 瘦不下來？Laravel 後台架構終極對決：Repository vs. Action 模式，資深工程師帶你選對屠龍刀！
• Laravel 效能卡關？Redis 就是你的神兵利器！從快取到隊列，資深工程師帶你榨乾系統效能
• API 的數位身分證？深入淺出 Laravel JWT，從原理到安全實戰的終極指南

如果你對 Laravel 開發、網站效能優化，或是任何企業級系統架構有更深入的需求，浪花科技的團隊擁有豐富的實戰經驗。我們不只會寫 Code，我們更專注於打造穩固、高效且可擴展的數位解決方案。歡迎與我們聯繫，讓我們的專業成為你最強的後盾！