Trong nội dung bài viết này chúng ta sẽ cùng tìm hiểu về một sự việc kể đến tương đối nhiều vào Laravel chính là Repository Pattern. Với gần như bạn new khám phá về Laravel chắc hẳn rằng cũng không nhiều chú ý mang lại vấn đề này. Còn chúng ta đi thực tập tại các cửa hàng, những ban trainee thì kiên cố chạm chán sẽ tiến hành những trainer của chính mình kể đến tự khóa này. Vậy nó là gì nhưng mà, bao gồm thực sự quan trọng ko, chúng ta cùng khám phá nhé.Quý khách hàng đang xem: Repository là gì

1. Khái niệm

Đầu tiên để phát âm về định nghĩa họ đã cùng coi hình họa bên dưới đây

*

Repository Pattern là một trong giải pháp tổ chức triển khai source code vào Laravel.Nhìn vào ảnh này các ban có thể tưởng tượng qua qua nó rồi chđọng, Repository Pattern là lớp trung gian giữa tầng Data Access với Business Logic, gọi môm mãng cầu thì nó là lớp trung gian giữa những việc truy cập dữ liệu với xử trí súc tích. giúp cho câu hỏi truy vấn tài liệu ngặt nghèo và bảo mật thông tin rộng.

Bạn đang xem: Repository là gì

Bình hay để mang tài liệu nào đấy hiển thị ra view thì chúng ta dễ dàng viết một Controller query cho Database để mang ra dữ liệu. Nhưng với Repository pattern nlỗi hình trên bọn họ thấy Repository nó nằm trong lòng, là trung gian thân Controller với Model. Hiểu đơn giản và dễ dàng thì như thế này, khi tất cả request điện thoại tư vấn tới controller, controller hotline tới Repository rồi thằng này hotline tới model rước data cùng cách xử trí, controller rước tài liệu thì chỉ việc Điện thoại tư vấn mang đến thằng này.Lí tngày tiết thì nói vậy thôi chứ còn để vận dụng nó vào dự án công trình thì chúng ta đã coi ví dụ tiếp sau đây nhé

2. Sử dụng Repository pattern vào Laravel

Bây tiếng giả sử mình gồm một lớp Post và những bạn muốn lấy ra list thành phầm bố trí theo ID giảm dần?

Đề bài xích hơi là easy đề xuất không đơn giản và dễ dàng là vào PostController viết một hàm

public function getPost() $posts = Post::orderBy("id", "desc")->get(); return view("post.index", compact("posts"));Vậy là hoàn thành easy cần không, Còn ví như viết theo Repository pattern thì họ vẫn phải tạo lập thêm một tờ là PostRepository trong một tlỗi mục tên là Repositories, thỏng mục này vào app/

namespace AppRepositories;use AppModelsPost;class PostRepository public function getPostById() return Post::orderBy("id", "desc")->get(); Và vào PostController bây giờ họ vẫn viết

class PostController extends Controller protected $postRepository; public function __construct(PostRepository $postRepository) $this->postRepository = $postRepository; public function getPost() $posts = $this->postRepository->getPostById(); return view("post.index", compact("posts")); Đến đây thì những bạn sẽ tự hỏi, sao lại đề nghị mất công, sẽ từ một lớp đem dữ liệu ngon cơm lại bắt buộc viết thêm một tấm nữa ?? Dữ liệu mang ra cũng như vậy chả khác gì, cơ mà ban sơ chỉ mất vài ba loại code là đem được, tiếng tốn thêm cả chục mẫu code nữa, tại vì sao lại bắt buộc điều đó ??.

Mình Lúc mới mày mò về repository cũng hỏi câu này nhều rồi

*

. Và mình chắc chắn rằng cũng một cơ số các bạn nữa Lúc bắt đầu tò mò về repository cũng đã có lần từ bỏ gồm thắc mắc này.

Các các bạn bao gồm thấy không, theo cách viết ko sử dụng repository thì Controller đã lắp chặt cùng thao tác làm việc trực tiếp new mã sản phẩm. Nếu Lúc nhưng mà Model có sự đổi khác giỏi tái cấu tạo bảng gì đó ví dụ như cột title làm việc bảng posts chúng ta bắt buộc cố lại là title_post ví dụ điển hình thì họ vẫn gặp rắc rối Khi đề xuất tra cứu code vào Controller coi nơi nào cần sử dụng đến vị trí đó để sửa. Hoặc cực khổ hơn là, nhu yếu người tiêu dùng thay đổi vào cái ngày trời nắng nóng lớn ông ấy tận hưởng họ mang theo ID giảm dần nỗ lực tê, rồi vào trong 1 ngày mưa to lớn ông ấy lại thử dùng lấy theo lượng view sút dần . Biết làm sao được nên chiều ý người tiêu dùng thôi.

Easy thôi, vào Controller tra cứu chỗ nào orderBy ID desc sửa thành orderBy view desc là dứt. Nhưng vấn đề tại một dự án họ đang thực hiện function đó các lần và rất có thể là trong không ít Class không giống nhau. khi đó thì bọn họ đang cần lần dò các Class trong Controller coi ở đâu bao gồm nhằm sửa điều này thì vượt mất thời gian, chưa kể trong những khi sửa không may xóa nhầm tuyệt thêm sút gì đó trong code hoặc sửa thiếu thốn một vài ba nơi, rồi lại ngồi tìm bug thì rất là phiền phức. Lúc này chính là dịp Repository đẩy mạnh chức năng.

Xem thêm: Ca Sĩ Tuấn Anh Là Ai - Thông Tin, Tiểu Sử Về Ca Sĩ Tuấn Anh

Chưa không còn đâu. Tiếp nhé, tiếng ko nắng và nóng cũng không mưa nữa rồi, trời bắt đầu tất cả gió thì ông quý khách hàng tê lại giới thiệu những hiểu biết là sử dụng MongoDB hoặc Redis để lưa dữ liệu . Thôi đành chiều ý ông kia vậy. Chúng ta sẽ đề nghị tìm kiếm PostRepository vừa rồi với thay đổi lại thành những PostRepositoryRedis xuất xắc PostRepositoryMongo... Ok, không vấn đề gì sửa thôi,sửa ngừng vài ngày thì thì ông kia lại không lại muốn trở lại như cũ. Đến đó là bao gồm vấn đề rồi. Vậy chiến thuật là gì?

Để giải quyết sự việc bên trên chúng ta sẽ tạo nên ra một Interface bình thường cho các một số loại repositories. Để làm được điều này bọn chúng ra sẽ khởi tạo thêm 1 thư mục là Contracts với phía bên trong sinh sản thêm một thư mục tên là Repositories để viết Interface tầm thường nhỏng đã nói trên vào đó, tiếp đến tạo thành một interface tên là PostRepositoryInterface ở trong số đó. Tên bản thân đặt kia là ko cần nhé các bạn có thể khắc tên khác. Hoặc viết thư mục Contracts phía bên trong thỏng mục Repositories tạo thành thuở đầu cũng khá được. Tất nhiên là với cùng 1 dự án công trình thì chúng ta buộc phải kiến tạo những Interface ví dụ này bản thân kiến thiết mang đến Post. ví dụ như một blog thì họ còn cần tạo ra Interface cho Tag, Question... các Interface này sẽ đặt hết vào AppContractsRepositories nhé.

namespace AppContractsRepositories;interface PostRepositoryInterface public function getPostById(); ...Và bây giờ họ vẫn có 1 interface nlỗi một khuôn mẫu chúng để cho các Repositories sinh sống bên trên implement. Nếu vào project chúng ta gồm không chỉ có PostRepositoryInterface nhưng mà còn có những Interface khác như TagRepositoryInterface, QuestionRepositoryInterface. Và chúng ta nhận biết là trong những Interface này có phần nhiều function tương tự như nhau như all(), update(), create().... Các function cơ mà Interface nào thì cũng thấy bao gồm thì các bạn yêu cầu xây cất một Interface chung nhằm knhị báo những hàm phổ biến trong đó, cùng từ bây giờ PostRepositoryInterface, TagRepositoryInterface, QuestionRepositoryInterface đã extend từ bỏ mẫu Interface bình thường vừa nói trên đặt nó là AbstractRepositoryInterface

namespace AppContractsRepositories;interface AbstractRepositoryInterface public function model(); public function all(); public function store(array $data); public function show($id); public function edit($id); ....Và giả dụ đề xuất một function riêng nào đó không tồn tại trong AbstractRepositoryInterface thì bọn họ chỉ việc knhị báo thêm trong những Interface extend

namespace AppContractsRepositories;interface PostRepositoryInterface extends AbstractRepositoryInterface public function pending($id); public function getTags($id); .....Lúc bấy giờ thì PostRepository họ vừa viết dịp nãy sẽ implements từ PostRepositoryInterface đang cần gồm chút ít đổi khác nlỗi sau

namespace AppRepositories;​use AppModelsPost;​class PostRepository implements PostRepositoryInterface{ //override public function getPostById() return Post::orderBy("id", "desc")->get(); Redis xuất xắc Mongo thì giống như cũng trở thành implements trường đoản cú PostRepositoryInterface.Và hiện thời trong PostsController chúng ta sẽ cụ đổi

class PostsController extends Controller protected $postRepository; public function __construct(PostRepositoryInterface $postRepository) $this->PostRepository = $postRepository; public function getPost() $post = $this->postRepository->getPostById(); return $post; Nhớ thêm namspaces PostRepositoryInterface nữa đó.

Các các bạn bao gồm nhận thấy điều gì không, khi họ đổi khác PostsController cố kia thì Khi chạy vững chắc chắc sẽ bị báo lỗi bởi vì PostRepositoryInterface là 1 trong những Interface với tất yếu Interface thì quan yếu chế tác instance được, chúng ta không thể inject Interface vào Controller. Nhưng với Laravel thì được đấy, cùng với Service container nó rất có thể góp chúng ta bind một interface vào trong 1 implement của chính nó. Các chúng ta có thể mày mò Service container cùng Denpendency Injection để hiểu rõ rộng những thao tác làm việc của chính nó nhé.

Tiếp theo bọn họ đề xuất vào tlỗi mục Providers với tìm tới AppServiceProvider để đăng kí. Trong cách thức register() họ vẫn thêm.

Xem thêm: Khánh Phương Cao Bao Nhiêu, Fc Khánh Phương, Just A Moment

public function register() $this->app->bind( "AppContractsRepositoriesPostRepositoryInterface", "AppRepositoriesPostRepository" );vì vậy là chúng ta vẫn đăng kí ngừng với rất có thể inject PostRepositoryInterface vào PostController. Nếu dự án chúng ta bắt buộc bind những Interface thì tốt nhất là đề nghị tạo ra một file riêng rẽ trong app/Providers chứ không duy nhất thiết bắt buộc cần sử dụng AppServiceProvider. Nếu dung giải pháp tạo nên file mới, thì yêu cầu knhì báo file kia config/phầm mềm.php với cung ứng providers nhé

Vậy là qua bài này tôi đã reviews hoàn thành mang lại các bạn về Repository Pattern vào Laravel. Hy vọng rất có thể góp các bạn vẫn mong khám phá cùng mong muốn clean code có thể phần như thế nào hiểu được với vận dụng.

liên kết tmê say khảo:

https://londonrocknroll.com/p/laravel-design-patterns-series-repository-pattern-part-3-ogBG2l1ZRxnLhttps://londonrocknroll.com/p/tim-hieu-ve-service-container-trong-laravel-Qbq5QLw3lD8http://phpviet.net/repository-pattern-trong-laravel/


Chuyên mục: KHÁI NIỆM
Bài viết liên quan

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *