TÌM HIỂU VỀ REPOSITORY PATTERN LÀ GÌ ? SỬ DỤNG REPOSITORY PATTERN TRONG LARAVEL

một năm trướcCập nhật 6 mon trước3,81513 phút đọcCó khá nhiều bạn vẫn tận hưởng mình một bài viết về Repository Design Pattern. Vậy mục tiêu của nó là gì? Nó bao gồm thực sự cần thiết mang đến vận dụng của bạn xuất xắc không? Những ưu thế, nhược điểm của nó là gì? Chúng ta thuộc đi sâu tò mò qua bài viết này nhé.

Bạn đang xem: Tìm Hiểu Về Repository Pattern Là Gì ? Sử Dụng Repository Pattern Trong Laravel


*

Repository Design Pattern cùng áp dụng của nó vào Laravel

Repository Design Pattern là gì?

Đây là 1 trong mẫu xây dựng nâng cao cơ mà chúng ta bắt đầu xúc tiếp lập trình sẵn có lẽ rằng cũng không xem xét về nó lắm. Đối với các bạn đã có kinh nghiệm tay nghề thực tập xuất xắc thao tác nghỉ ngơi các công ti - có lẽ rằng cũng đã được nghe những mentor của chính bản thân mình nói đến nó. 

Repository Design Pattern (mình sẽ trợ thì viết tắt nó thành RD) là một trong những trong số những mẫu kiến tạo được áp dụng nhiều nhất vào hầu hết các ngôn từ lập trình, những framework... nlỗi .NET, Java, PHP...., trải nhiều năm tự websites, services, applications,... xuất xắc tất cả sản phẩm điện thoại apps. 

*

RD là 1 trong lớp trung gian thân Business Logic (BL) với Data Source (DB), các đối tượng vào lớp trung gian này được điện thoại tư vấn là Repository. Giao tiếp thân BL và DB sẽ được tiến hành trải qua các Interface.

Chúng đưa về sự chuẩn hóa (standardized) mang lại output cùng tách bóc biệt trọn vẹn câu hỏi up load business xúc tích và data access lô ghích, giúp cho BL trọn vẹn ko cần quyên tâm tới công việc của DB (cùng ngược lại). Việc chia nhằm trị này hướng đến mục tiêu: ai thao tác nấy, điều này cũng khiến code của doanh nghiệp sáng sủa rộng, cụ thể hơn, và dễ dàng maintenance hơn.

Nói một ví dụ thực tiễn - vào một xí nghiệp sản xuất may mặc, mỗi công nhân phần lớn hồ hết được phân chia theo team, và từng đội chỉ làm cho một trong những phần nhỏ tuổi trong khâu cung cấp. Có nhóm thì Chịu trách nát nhiệm may cổ áo, đội may tay áo, nhóm may thân áo, nhóm ráp các bộ phận đó lại cùng nhau, team chịu đựng trách rưới nhiệm hấp ủi... Một nhóm chỉ tập trung vào trong 1 quá trình cụ thể chắc chắn rằng đang nhanh hao cùng ít tạo thành thành phầm lỗi rộng so với một tín đồ làm cho từ đầu cho cuối đúng không nhỉ nào? ^^

 

Lợi ích của Repository Design Pattern

Code dễ cách tân và phát triển và maintenance khi làm việc theo team.Giảm tphát âm biến hóa code Lúc bao gồm biến hóa về cấu tạo dữ liệu, DB hoặc BL.BL với DB hoàn toàn có thể thử nghiệm độc lậpChuẩn hóa Áp sạc ra dữ liệuGiảm tphát âm trùng lặp code (DRY - Don"t Repeat Yourself)

 

Cũng hữu ích chưa ổn hại

Viết các, viết mệt nhọc, cái gì rồi cũng đề xuất nghĩ đến tách tránh cùng mang xuống Repository và tái áp dụng =))Dự án nhỏ tuổi, mì ăn uống tức thì thì ko bắt buộc xài cũng đượcVới câu hỏi trái đất vẫn đưa dần dần quý phái microservice thì bài toán vận dụng RD cho mỗi đôi mắt nhỏ tuổi trong microservice khá là dư quá và tốn nhiều chi phí vạc triển

 

Repository Design Pattern với Laravel

Nãy tiếng nói lan man vượt, toàn là kỹ năng khô ráo =)), giờ đồng hồ mình xin được phép liên tiếp phần chính của nội dung bài viết.

Trong Laravel, Repository là "cây cầu dừa" nối giữa Model và Controller, đó cũng là địa điểm tập trung up date những lô ghích tróc nã vấn dữ liệu.

Các truy tìm vấn này trước đó được triển khai trực tiếp ở Controller bây chừ sẽ được đưa vào Repository, thời điểm này Controller đã thúc đẩy với DB thông qua Repository nuốm do Điện thoại tư vấn trực tiếp Model. Việc triển khai truy hỏi vấn ra sao sẽ được Repository giấu bí mật bên phía trong (và Controller bạn dạng thân nó cũng chẳng buộc phải quan tâm, cđọng trả đúng - đầy đủ dữ liệu về mang đến nó là được rồi).

Vấn đề này tương tự như các bạn ra bank rút chi phí vậy. Quý khách hàng chỉ rất có thể gởi thử khám phá tới nhân viên bank, tiếp đến nhân viên cấp dưới bank kiểm soát cùng rước tiền gửi cho mình. Quý Khách demo từ xông vào đem chi phí coi sao, vô tù nhân tách bóc định kỳ là tất cả nha =))

Ủa rồi phần xử lý BL đâu rồi?

Không bắt buộc bản thân code cùi cần vứt thẳng phần up date BL vào trong Controller những điều đó đâu nha chúng ta =)) 

Trên thực tiễn, một vài làm việc get dữ liệu đơn giản sẽ được hotline thẳng ở Controller thông qua Repository.

Đối cùng với các business phức hợp sẽ sở hữu thêm 1 tầng Service ở giữa nữa. có nghĩa là hôm nay, Controller chỉ có trách nhiệm điều hướng up date xúc tích và ngắn gọn xuống Service, và Service new là chỗ tiến hành các BL với cập nhật xuống DB

Phần Service này mình vẫn nói rõ thêm cùng với các bạn ở 1 nội dung bài viết khác, dù sao bài viết này cũng chỉ nói tới RD thôi mà lại đúng không nhỉ ^^

 

Triển khai Repository Design Pattern dễ dàng cho Laravel

Khách sản phẩm của chúng ta cần xây đắp một mạng xã hội chất nhận được các publishers share những albums ảnh với tìm chi phí donate cũng như sự danh tiếng.

Xem thêm: Giải Thích Vì Sao Lợn Và Gia Cầm Được Nuôi Nhiều Ở Đồng Bằng ?

Trước hết họ sẽ xây dựng dựng một Model.

// app/Album.php namespace App;use IlluminateDatabaseEloquentModel;class Album extends Model protected $guarded = < "id", "created_at", "updated_at", >;Tiếp nối là Controller

// app/Http/Controllers/AlbumController.phpnamespace AppHttpControllers;use AppAlbum;class AlbumController extends Controller /** * Nội dung trang Albums List */ public function index() $albums = Album::all(); return $albums; /** * Nội dung trang Albums Details */ public function show($id) $album = Album::findOrFail($id); return $album; Trong Controller, Album được hotline trực tiếp để truy vấn tài liệu. Mọi chuyện số đông êm rất đẹp cho đến lúc người sử dụng mong mỏi biến đổi biện pháp tầm nã vấn dữ liệu: những Album sẽ tiến hành bố trí theo độ can dự, số lượng views, hoặc trang Album Details được truy nã vấn bởi hash_id thế bởi vì id... Chắc chắn họ đã cần phải update lại Controller nhằm truy tìm vấn tài liệu đến phù hợp cùng với requirements của khách hàng.

Điều này rất là nguy hại với củ chuối. Bạn test tưởng tượng không chỉ là có mỗi AlbumController triển khai các thao tác như thế này, mà lại tương đối nhiều Controller khác cũng tiến hành điều tựa như. Việc update code các chỗ những điều đó vẫn làm tăng năng lực loại trừ hoặc làm việc sai trái.

Và đây là lúc Repository lên sàn =))

Chúng ta sẽ tạo một Repository như sau

// app/Repositories/Eloquent/AlbumRepository.phpnamespace AppRepositoriesEloquent;use AppAlbum;class AlbumRepository public function all() return Album::orderBy("views_count", "desc")->all(); public function find($id) return Album::firstOrFail(<"hash_id" => $id>); Cập nhật lại văn bản Controller

// app/Http/AlbumController.phpnamespace AppHttpControllers;use AppAlbum;use AppRepositoriesEloquentAlbumRepository;class AlbumController extends Controller protected $albumRepository; public function __construct(AlbumRepository $albumRepository) $this->albumRepository = $albumRepository; public function index() $albums = $this->albumRepository->all(); return $albums; public function show($id) $album = $this->albumRepository->find($id); return $album; Vậy là từ tiếng trsống đi, bạn phải thêm súc tích gì cứ chui vào Repository nhưng sửa, ví dụ - thật sạch sẽ - thô nháng - dễ dàng nắm bắt bắt buộc không làm sao ^^

 

Câu chuyện vẫn không tới hồi kết

Vào một ngày nọ, quý khách hàng của họ nghe phong pkhô giòn nơi nào đó nói rằng dữ liệu của website mình hầu hết tín đồ ta chỉ tất cả coi là thiết yếu, không phải update gì những cả. Kết thúc lịch trình, ông quý khách hàng trải nghiệm bọn họ gọi tài liệu lên từ cabít thay vày truy vấn DB như ngày nay. 

Giờ bọn họ nên làm cho sao? Sửa lại những hàm vào AlbumRepository chăng?

Sai. Chúng ta sẽ khởi tạo ra một repository không giống chịu trách nát nhiệm xử lí caching cho AlbumRepository.

Tại trên đây mình vẫn vận dụng một mẫu xây cất không giống, đó chính là Decorator Pattern. Mẫu kiến thiết này giúp chúng ta thêm những tính năng lạ cơ mà không cần thiết phải update lại các lớp bây chừ (lớp ở đó chính là AlbumRepository).

// app/Repositories/Cache/AlbumRepositoryCacheDecorator.phpnamespace AppRepositoriesCache;use AppRepositoriesEloquentAlbumRepository;;class AlbumRepositoryCacheDecorator protected $repository; public function __construct() $this->repository = new AlbumRepository(); public function all() /*If cađậy exists, get data from cache*/ if ("has-cache") return "data-from-cache"; $albums = $this->repository->all(); /*Logic khổng lồ store cache*/ return $albums; public function find($id) /*If cađậy exists, get data from cache*/ if ("has-cache") return "data-from-cache"; $album = $this->repository->find($id); /*Logic khổng lồ store cache*/ return $album; public function update($id, array $data) $this->repository->update($id, $data); /*Logic to clear cache*/ Sau đó bọn họ cần import AlbumRepositoryCacheDecorator núm vì AlbumRepository

// app/Http/AlbumController.phpnamespace AppHttpControllers;use AppRepositoriesCacheAlbumRepositoryCacheDecorator;class AlbumController extends Controller protected $albumRepository; public function __construct(AlbumRepositoryCacheDecorator $albumRepository) $this->albumRepository = $albumRepository; public function index() $albums = $this->albumRepository->all(); return $albums; public function show($id) $album = $this->albumRepository->find($id); return $album; Các bạn phải chăm chú sự biến đổi ngơi nghỉ đây: họ đã thay đổi trang bị được inject vào __construct

Củ chuối lắm các bạn à. Bởi AlbumRepository không chỉ có được sử dụng ở AlbumController nhỏng ví dụ bên trên, nó còn rất có thể được thực hiện sinh sống sản phẩm tá chỗ khác, ví như nlỗi chúng ta cập nhật một bí quyết thủ công điều này vẫn hoàn toàn có thể dẫn mang lại những lỗi không thích, và khiến code của chúng ta lặp đi lặp lại nhiều lần.

Với sự trợ giúp của Laravel Service Container, chúng ta có thể bind một interface cho tới một class một mực. 

Trước hết chúng ta sẽ tạo ra một interface như sau

// app/Repositories/Contracts/AlbumRepositoryContract.phpnamespace AppRepositoriesContracts;interface AlbumRepositoryContract public function all(); public function find($id);Sau kia họ đề nghị chỉnh sửa nội dung cho nhị lớp AlbumRepository và AlbumRepositoryCacheDecorator sao cho chúng implements AlbumRepositoryContract bên trên.

use AppRepositoriesContractsAlbumRepositoryContract;class AlbumRepository implements AlbumRepositoryContract class AlbumRepositoryCacheDecorator implements AlbumRepositoryContract Bước tiếp đến đặc biệt quan trọng nhất: họ đề nghị knhì báo đến Laravel biết cách up load lúc bọn họ gọi interface binding. Chúng ta vẫn update văn bản cách thức register phía bên trong tập tin app/Providers/AppServiceProvider.php.

namespace AppProviders;use IlluminateSupportServiceProvider;use AppRepositoriesContractsAlbumRepositoryContract;use AppRepositoriesCacheAlbumRepositoryCacheDecorator;class AppServiceProvider extends ServiceProvider{ /** * Register any application services. * *

Leave a Reply

Your email address will not be published. Required fields are marked *

x

Welcome Back!

Login to your account below

Retrieve your password

Please enter your username or email address to reset your password.