站長資訊網(wǎng)為什么要在 Laravel 中使用存儲庫模式（Repository）？下面本篇文章給大家介紹一下使用存儲庫模式的優(yōu)點，希望對大家有所幫助！
Laravel 9 保姆級視頻教程，想學不會都難！進入學習
- 1. Laravel中的存儲庫模式
- 2. 為什么要在 Laravel 中使用存儲庫模式（Repository）？
在之前的文章中，我解釋了什么是存儲庫模式，它與Active Record模式有何不同，以及如何在Laravel中實現(xiàn)它?，F(xiàn)在我想深入了解一下為什么應該使用存儲庫模式。
我在上一篇文章的評論中注意到，Repository模式在Laravel社區(qū)中是一個有爭議的話題。有些人認為沒有理由使用它，并堅持使用內(nèi)置的Active Record模式。其他人則傾向于使用其他方法將數(shù)據(jù)訪問從邏輯域中分離出來。請注意，我尊重這些意見，并將在接下來的博客文章中專門討論此主題。
有了這個免責聲明，讓我們來了解一下使用存儲庫模式的優(yōu)點。
單一責任原則
單一責任原則是主要鑒別器來區(qū)分Active Record模式和存儲庫模式。模型類已經(jīng)保存數(shù)據(jù)并提供域?qū)ο蟮姆椒ā．斒褂肁ctive Record模式時，數(shù)據(jù)訪問是額外引入的責任。這是我想在以下示例中說明的東西：
/** * @property string $first_name * @property int $company_id */ class Employee extends Model {} $jack = new Employee(); $jack->first_name = 'Jack'; $jack->company_id = $twitterId; $jack->save();
雖然域模型和數(shù)據(jù)訪問技術的職責混合，但它直觀上看還說得過去。在我們的應用程序中，員工必須以某種方式存儲在數(shù)據(jù)庫中，因此為什么不調(diào)用對象上的save()。單個對象被轉化成單個數(shù)據(jù)行并存儲。
但是，讓我們更進一步，看看我們還能對員工做些什么：
$jack->where('first_name', 'John')->firstOrFail()->delete(); $competition = $jack->where('company_id', $facebookId)->get();
現(xiàn)在，它變得不直觀，甚至違背了我們的域模型。 為什么 Jack 會突然刪除另一個甚至可能在不同公司工作的員工？ 或者他為什么能把 Facebook 的員工拉過來？
當然，這個例子是人為設計的，但它仍然顯示了 Active Record 模式如何不允許有意的域模型。 員工與所有員工列表之間的界限變得模糊。 您始終必須考慮該員工是被用作實際員工還是作為訪問其他員工的機制。
倉庫模式通過強制執(zhí)行這個基本分區(qū)來解決這個問題。它的唯一用途是標識域?qū)ο蟮暮霞皇怯驅(qū)ο蟮谋旧怼?/strong>
要點:
- 通過將所有域?qū)ο蟮募吓c單個域?qū)ο蠓蛛x， 倉庫模式體現(xiàn)了單一責任原則 。
不要重復自己 (DRY)
一些項目將數(shù)據(jù)庫查詢?yōu)⒈榱苏麄€項目。下面是一個例子，我們從數(shù)據(jù)庫中獲取列表，并在 Blade 視圖中顯示他們。
class InvoiceController { public function index(): View { return view('invoices.index', [ 'invoices' => Invoice::where('overdue_since', '>=', Carbon::now()) ->orderBy('overdue_since') ->paginate() ]); } }
當這樣的查詢遍得更加復雜并且在多個地方使用時，考慮將其提取到 Repository 方法中。
存儲庫模式通過將重復查詢打包到表達方法中來幫助減少重復查詢。如果必須調(diào)整查詢，只需更改一次即可。
class InvoiceController { public __construct(private InvoiceRepository $repo) {} public function index(): View { return view('invoices.index', [ 'invoices' => $repo->paginateOverdueInvoices() ]); } }
現(xiàn)在查詢只實現(xiàn)一次，可以單獨測試并在其他地方使用。此外，單一責任原則再次發(fā)揮作用，因為控制器不負責獲取數(shù)據(jù)，而只負責處理HTTP請求和返回響應。
Takeaway:
- ? 存儲庫模式有助于減少重復查詢
依賴反轉
解釋 Dependency Inversion Principle 值得發(fā)表自己的博客文章。我只是想說明存儲庫可以啟用依賴項反轉。
在對組件進行分層時，通常較高級別的組件依賴于較低級別的組件。 例如，控制器將依賴模型類從數(shù)據(jù)庫中獲取數(shù)據(jù)：
class InvoiceController { public function index(int $companyId): View { return view( 'invoices.index', ['invoices' => Invoice::where('company_id', $companyId)->get()] ); } }
依賴關系是自上而下的，緊密耦合的。 InvoiceController 取決于具體的 Invoice 類。 很難將這兩個類解耦，例如單獨測試它們或替換存儲機制。 通過引入 Repository 接口，我們可以實現(xiàn)依賴倒置：
interface InvoiceRepository { public function findByCompanyId($companyId): Collection; } class InvoiceController { public function __construct(private InvoiceRepository $repo) {} public function index(int $companyId): View { return view( 'invoices.index', ['invoices' => $this->repo->findByCompanyId($companyId)] ); } } class EloquentInvoiceRepository implements InvoiceRepository { public function findByCompanyId($companyId): Collection { // 使用 Eloquent 查詢構造器實現(xiàn)該方法 } }
Controller 現(xiàn)在只依賴于 Repository 接口, 和 Repository 實現(xiàn)一樣. 這兩個類現(xiàn)在只依賴于一個抽象, 從而減少耦合. 正如我將在下一節(jié)中解釋的那樣，這會帶來
