前言
關於專案中是否需要 Repository 層？這個問題，好像沒有肯定的答案，下面是我的思考分享給大家，不喜勿噴。
Repository 的定位
我理解 Repository 是個大倉庫，裡面可以有 MySQL、Redis、MongoDB … 等資料。
維護這一層的開發者，可以稱為 倉庫管理員 ，當使用者需要查詢資料的時候，需要告訴倉庫管理員，由倉庫管理員拿給他，至於倉庫管理員從哪拿的資料，使用者無需關係。
同理，當需要建立或更新資料的時候，也需要告訴倉庫管理員，由倉庫管理員進行運算元據。
總結：Repository 主要是封裝資料的查詢、建立、更新、刪除等邏輯，供使用者呼叫。
Repository 的實現
- 可配置條件查詢
- 可配置資料轉換
- 可配置資料驗證
解釋下 “可配置資料轉換” ：當我們需要返回隱私性欄位時，例：如手機號，如果使用者無資料許可權時，手機號欄位中間 4 位需要進行加 * 處理，還有處理返回的時間格式等。
如果你使用的是 Laravel 框架，可以參考下 andersao/l5-repository
Repository 的介面
Repository 層的介面可以理解為契約（可瞭解下 Laravel Contracts 目錄），它是受 Domain 驅動的，Repository 中定義的功能要體現 Domain 的意圖和約束。Domain 需要什麼我才提供什麼，不需要的我不會提供。
例如，介面名可以定義為 searchUsersById 、searchUsersByName，不可以定義為 searchUsersByInfo，查詢的欄位也不建議設定為 * ，僅查詢需要的欄位進行返回。
什麼是 Domain？可以理解為領域層。
小結
使用 Repository 層有利有弊，弊端就是有些繁瑣，沒有 ORM 一把梭的順暢。當然優點也有很多，主要是後期的可維護性大大提高。
列舉一些優點：
- 更換、升級
ORM引擎時，不影響業務邏輯； - 便於單元測試，可用
Mock物件代替實際的資料庫存取；
以上，希望對你能夠有所幫助。
推薦閱讀
本作品採用《CC 協議》，轉載必須註明作者和本文連結