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