Laravel Beauty: Tìm hiểu về Service Provider
Bài đăng này đã không được cập nhật trong 3 năm
Index
- Laravel Beauty: Recipes & Best Practices
- Laravel Beauty: Tìm hiểu về Service Container
- Laravel Beauty: Tìm hiểu về Service Provider
- Laravel Beauty: Tìm hiểu về Facade
- Laravel Beauty: Tìm hiểu về Contract
Mở đầu
Trong bài viết lần trước, chúng ta đã cùng tìm hiểu về thành phần trung tâm của Laravel Framework, đó là Service Container.
Nhìn chung thì Service Container trong Laravel là nơi quản lý class dependency và thực hiện dependency injection.
Bạn chỉ cần bind
một Class, Interface hay một từ khoá bất kỳ với Service Container là có thể resolve
chúng ra ở bất cứ nơi đâu.
Bản thân chính Laravel cũng thực hiện bind
rất nhiều thứ vào trong Service Container để chúng ta có thể gọi ra sử dụng khi cần thiết, bằng nhiều cách khác nhau.
Và trong bài viết này, ta sẽ tìm hiểu xem Laravel thực hiện việc bind
đó khi nào, ở đâu và bằng cách nào nhé. Từ đó ta sẽ có thể tự hiểu và tìm ra cách để thay thế một service có sẵn của Laravel bằng một service do chính mình implement một cách dễ dàng.
Tìm hiểu về Service Provider
Service Provider - Khai báo trong config/app.php
Chắc hẳn bạn đã động chạm nhiều đến file config này rồi khi làm việc với Laravel. Không chỉ là nơi setup những thông số của project như debug mod, url, timezone, local ..., ở file config/app.php
, bạn sẽ còn thấy một mục quan trọng khác, đó là providers, với những dòng comment ở phía dưới là
/*
* Laravel Framework Service Providers...
*/
/*
* Application Service Providers...
*/
Vâng, đây chính là nơi bắt đầu của việc registering service container bindings. Tuy nhiên thay vì luôn phải sử dụng app()->bind()
, app()->instance()
... như đã đề cập ở bài viết trước, thì ở phần khai báo bindings trong file config/app.php
này ta lại truyền vào tên các class. Mà các class đó thường được đặt tên dưới dạng là SomethingServiceProvider, chẳn hạn như Illuminate\Session\SessionServiceProvider
, Illuminate\View\ViewServiceProvider
, Illuminate\Routing\ControllerServiceProvider
...
Ngoài ra, chắc bạn cũng đã từng để ý là thường thì ở các package Laravel mà các bạn vẫn hay dùng, như Laravel Debugbar, Laravel Markdown, Laravel IDE Helper ..., khi cài đặt, các package đó đều yêu cầu các bạn add class ServiceProvider
của chúng vào phần providers trong config/app.php
. Hay nói các khác, các third-party package cho Laravel cũng thường xuyên cung cấp Service Provider để quá trình cài đặt và sử dụng được dễ dàng.
Vậy rốt cuộc Service Provider là gì?
Service Provider - Từ khái niệm đến thực tiễn
Như đã nói ở trên, trong project được tạo ra, ngoài file bootstrap/app.php
có khai báo binding Kernel và Exception ra thì bạn sẽ không thấy nơi nào khai báo binding một cách trực tiếp nữa. Thay vào đó chỉ có nơi khai báo class sẽ thực hiện việc binding, những class đó chính là Service Provider.
Các Service Provider đều được extend từ một abstract class mà Laravel cung cấp, đó là Illuminate\Support\ServiceProvider
. Nếu bạn vào tìm hiểu code của class này thì sẽ thấy nó bao gồm một abstract function là register
, điều đó có nghĩa là Service Provider của bạn viết sẽ bắt buộc phải khai báo method register
này. Và đây chính là nơi bạn thực hiện việc binding vào Service Container. Chẳng hạn hãy cùng xem một Service Provider đơn giản là HashServiceProvider
xem nó có gì nhé.
Bình thường, vào file config/app.php
bạn sẽ thấy providers đó được khai báo dưới dạng Illuminate\Hashing\HashServiceProvider::class
, dựa trên cái tên đó ta có thể tìm ra file provider tại /vendor/laravel/framework/src/Illuminate/Hashing/HashServiceProvider.php
:
class HashServiceProvider extends ServiceProvider
{
/**
* Indicates if loading of the provider is deferred.
*
* @var bool
*/
protected $defer = true;
/**
* Register the service provider.
*
* @return void
*/
public function register()
{
$this->app->singleton('hash', function () { return new BcryptHasher; });
}
}
Như vậy ta có thể thấy trong HashServiceProvider
ta đã thực hiện việc binding từ khoá hash
, có thể coi đây là tên service, với một instance của class BcryptHasher
qua method singleton
. Như vậy thì:
get_class(app()->make('hash'))
sẽ trả ra kết quả làIlluminate\Hashing\BcryptHasher
;app()->make('hash') === app()->make('hash')
sẽ trả ra kết quảtrue
, do các lần gọiapp()->make('hash')
ta đều sẽ nhận về cùng một object.
Bên cạnh đó, các bạn có thể thấy trong class HashServiceProvider
ở trên, ta còn có một biến protected là $defer
. Việc khai báo $defer = true
sẽ giúp cho quá trình binding sẽ không được thực hiện cho đến khi service được gọi. Hay nói cách khác, theo ví dụ ở trên thì với mỗi request, một instance của BcryptHasher
sẽ không phải được tạo ra ngay từ đầu, mà chỉ khi nào ta gọi app()->make('hash')
lần đầu thì việc binding mới diễn ra (và cũng sẽ chỉ diễn ra một lần, từ những lần gọi sau thì đã có trong Service Container rồi nên chỉ việc lấy ra mà thôi). Để thực hiện được việc này thì bên cạnh hàm register
, trong trường hợp $defer = true
thì ta cần phải có thêm một hàm nữa báo trước cho Laravel là cái provider này sẽ trả về service gì, đó là hàm provides
. Cụ thể thì hàm provides
của HashServiceProvider
trông như sau:
public function provides()
{
return ['hash'];
}
Như vậy thì ta có thể tóm tắt lại quá trình Laravel thực hiện xử lý các Service Provider như sau:
- Check xem biến
$defer
làtrue
hayfalse
. Nếu làfalse
thì thực hiện ngay việc binding thông qua việc chạy hàmregister
. - Nếu
$defer
làtrue
thì không chạy hàmregister
, thay vào đó sẽ lưu lại thông tin về việc service provider đó sẽ trả về service gì thông qua kết quả của hàmprovides
. Như vậy việc binding đã không diễn ra. - Khi ta yêu cầu resolve một service nào đó từ Service Container, Laravel sẽ check xem đó có phải là deferred service hay không, nếu đúng thì Laravel sẽ thực hiện việc chạy hàm
register
của provider tương ứng. Lúc này việc binding mới được diễn ra. Và đương nhiên sau khi binding xong thì service đó sẽ được remove ra khỏi danh sách các deferred service. Cuối cùng, việc resolve sẽ được thực hiện.
Việc load các service một cách defer như vậy sẽ giúp cái thiện performance cho application của bạn, khi mà những service chỉ được load khi mà nó là cần thiết. Đương nhiên nếu service của bạn là chắc chắn cần thiết, chắc chắn phải sử dụng thì bạn không cần khai báo $defer = true
làm gì, nó sẽ chỉ làm tăng thêm xử lý khi gọi ra lần đầu mà thôi.
Ngoài ra, còn một chú ý khác nữa là bạn chỉ nên thực hiện khai báo binding trong hàm register
, chứ không nên khai báo những event listener, routes hay các xử lý phức tạp khác. Bởi nên biết rằng Laravel sẽ duyệt qua một loạt các provider để thực hiện việc binding, thế nên có khả năng bạn sẽ gặp phải tình huống là gọi ra một service khi mà provider của nó còn chưa được xử lý.
Còn nếu muốn viết những xử lý có yêu cầu những service khác, thì bạn nên viết nó trong hàm boot
, bởi hàm này sẽ chỉ được gọi khi mà toàn bộ các service provider đã được duyệt qua, và vì thế, đương nhiên là bạn sẽ có thể access được vào toàn bộ các service.
Service Provider - Ứng dụng
Service Provider chính là chìa khoá cho quá trình bootstrapping một Laravel Application. Hãy tưởng tượng application của bạn như một cái Container, và khi khởi chạy, nó sẽ tiến hành đưa các service cần thiết vào trong container đó, rồi những gì bạn cần làm là lấy ra những service cần thiết vào thời điểm cần thiết từ container để xử lý một request gửi đến.
Việc được xây dựng dựa trên sự kết hợp của các service như vậy đã giúp Laravel có sự mềm dẻo và linh hoạt cần thiết. Trong quá trình làm việc với Laravel, khi đã nắm rõ khái niệm, vai trò và cách thức sử dụng Service Provider thì bạn hoàn toàn có thể ứng dụng nó vào các trường hợp chẳng hạn như:
- Bootstrapping application: Khi nhìn vào phần khai báo providers trong
config/app.php
, bạn sẽ thấy sẽ có phần cho Application Service Providers, và trong đó thì cóApp\Providers\AppServiceProvider
. Laravel đã tạo sẵn cho bạn một nơi lý tưởng để bạn có thể thêm vào những binding hay những bootstrapping config của mình. Chặng hạn như bạn muốn viết thêm những validation của riêng mình thông qua việc sử dụngValidator::extend
, hay muốn thêm vào những HTML Macro, hay bất cứ xử lý logic nào khác bạn cần chạy trước khi tiến hành xử lý request ..., thì hàmboot
trongAppServiceProvider
là nơi bạn nên thực hiện những việc đó việc đó. - Tự viết các service của mình: Nếu application của bạn có quá nhiều thứ cần bootstrap mà bạn cảm thấy viết hết vào hàm
boot
trongAppServiceProvider
là không tốt thì bạn nên nghĩ đến viết nhiều Service Provider khác nhau. Ngoài ra khi mà application của bạn được mở rộng, và có cấu trúc lớn thì một việc quan trọng được đặt ra là cần phải tổ chức các business logic như thế nào cho hợp lý. Và đương nhiên việc viết thành những service rồi khai báo qua Service Provider là một trong những cách mà bạn nên thử. Chẳng hạn như application của bạn có nhiều chỗ đòi hỏi làm việc với image, và đi cùng với đó sẽ là những hàm, những xử lý với image. Có thể khi đó bạn sẽ cần đến mộtImage
class là nơi chứa các logic function, và mộtImageServiceProvider
, với những xử lý binding và bootstrapping ở trong đó - Làm việc với các Laravel package: Như đã nói ở phần đầu thì các package Laravel thường có các Service Provider của riêng nó. Giờ thì bạn đã hiểu nó để làm gì, và tại sao cần phải khai báo trong file
config/app.php
rồi chứ.Và ngược lại, khi bạn muốn viết một package Laravel cho những người khác sử dụng thì cũng nên nhớ viết một Service Provider cho nó nhé. Khi đó service của bạn sẽ có thể được dùng dễ dàng hơn, và theo đúng phong cách Laravel hơn.
- Thay thế service mặc định của Laravel: Các service của Laravel giao tiếp với nhau thông qua Service Container. Ví dụ như một xử lý của bạn cần service Authentication thì bạn có thể lấy ra bằng cách dùng
app()->make('auth')
rồi tiếp tục tiến hành các xử lý tiếp theo. Như vậy xử lý của bạn cần service auth để chạy, chứ nó không hoàn toàn phụ thuộc vào một class Auth cố định nào cả. Điều này cũng có nghĩa là bạn hoàn toàn có thể tự viết một service của mình, một provider của riêng mình rồi thay khai báo provider của Laravel trongconfig/app.php
bằng khai báo provider của bạn, miễn là class service của bạn cũng có các method cần thiết giống như class service mặc định của Laravel (thường là sẽ phải implement một interface nào đó). Ví dụ như một package Laravel mà mình vẫn hay sử dụng là MultiAuth (https://github.com/Kbwebs/MultiAuth) (package cho Laravel 5.1, còn lên 5.2 thì bản thân Laravel đã hỗ trợ Multi Auth rồi). Bằng việc sử dụng package trên, mình có thể thực hiện authenticate với nhiều bảng khác nhau, nhưusers
vàadmins
chẳng hạn. Những gì mình cần làm để sử dụng nó chỉ đơn giản là thay đổi service provider mặc định, từIlluminate\Auth\AuthServiceProvider
thànhKbwebs\MultiAuth\AuthServiceProvider
, hayIlluminate\Auth\Passwords\PasswordResetServiceProvider
thànhKbwebs\MultiAuth\PasswordResets\PasswordResetServiceProvider
... và một vài config nhỏ khác.
Lời kết
Như vậy là mình đã giới thiệu qua về Service Provider, vai trò, ý nghĩa, cũng như cách nó đang được sử dụng trong một project Laravel ra sao. Dĩ nhiên, cũng chỉ dừng ở mức cơ bản mà thôi. Bạn có thể tự vào đọc code của framework để hiểu rõ hơn về cách thức mà Laravel thực hiện cách load và chạy Service Provider như thế nào.
Hay như phần khai báo providers ở file config/app.php
, không phải tất cả các service đều được khai báo ở đó đâu. Chẳng hạn như bạn gõ app()->make('request')
, app()->make('events')
, hay app()->make('url')
thì đều sẽ nhận được object tương ứng, tuy nhiên ta lại không hề thấy những RequestServiceProvider
, EventsServiceProvider
hay UrlServiceProvider
nào trong phần khai báo ở config/app.php
cả. Thậm chí lục tung cả framework Laravel lên thì bạn cũng không tìm đâu ra cái gọi là RequestServiceProvider
hay UrlServiceProvider
đâu. Vậy những service đó được binding ở đâu, vào lúc nào, hay nếu có Service Provider tương ứng thì provider đó được gọi như thế nào? Hãy thử tự cố gắng tìm câu trả lời xem, chắc chắn khi tìm hiểu xong, bạn sẽ thấy mình hiểu nhiều hơn về cách thức hoạt động của Laravel đấy.
Hẹn gặp lại các bạn trong những bài viết giới thiệu về những khái niệm như Contracts hay Facades sắp tới ^^!
All rights reserved
Bình luận
Cảm ơn anh. (thankyou) Bài viết rất hữu ích. Quả nhiên là ít người đi được tới bài này (hihi)
Nếu $defer là true thì không chạy hàm register. mình thấy $defer = true | false thì nó đều chạy hàm register à bạn
Tại sao bạn lại thấy như vậy
Cụ thể bạn đã làm những gì để ra kết quả đó?
Mà trong bài viết mình đề cập việc set
$defer
làtrue
thì service sẽ được load khi nó lần đầu tiên được gọi đến, và lúc này hàmregister
sẽ được chạy mà, chứ ý mình không phải là set$defer = true
thì hàmregister
sẽ mãi mãi không được chạy.Bạn có thể tìm hiểu thêm về Deferred Providers trên Document của Laravel, trên đó có nói rõ:
Ngoài ra, bạn cũng có thể xem thêm về code của Framework để kiểm tra cách nó load
deferred providers
, cụ thể là ở filelaravel/framework/src/Illuminate/Foundation/Application.php
.Anh cho em hỏi tí về phần "defer = true | false" Nếu là true thì có nghĩa là hàm register lúc này chưa được gọi => class chưa được bind Nếu là false thì có nghĩa là hàm register lúc này được gọi => class được bind
Ở cả 2 trường hợp em gọi app()->make('hash') thì "defer = true | false" đều trả về class ( Theo em hiểu từ bài viết của anh thì nếu defer = false thì make nó sẽ get được luôn instance còn defer = true thì vào chay register để bind và get instance)
Kiến thức còn hạn hẹp nên mong được anh giúp đỡ !
@cuong077
Không phải em ạ, như anh đã đề cập ở trong bài viết thì
tức nếu em để
$defer = false
, thì ngay cả trước khi em resolve raapp()->make('hash')
thì instance của classHashServiceProvider
đã được tạo ra rồi (trong quá trình bootstrap Laravel Framework), còn nếu em để$defer = true
, thì chỉ khi nào em gọiapp()->make('hash')
lần đầu, Laravel mới thực hiện tìm kiếm xem làm thể nào để resolve ra instance tương ứng, hay nói cách khác, chỉ khi nào em gọiapp()->make('hash')
lần đầu, thì việc binding một instance của classHashServiceProvider
với từ khoáhash
mới được thực hiệnThế nên dù em có gọi
app()->make('hash')
trong trường hợp$defer
bằngtrue
hayfalse
đi chăng nữa thì kết quả nó vẫn sẽ giống nhau thôi, điểm khác nhau là kết quả của hàmapp()->make('hash')
đó được tính toán sẵn và lưu lại từ lúc khởi chạy framework, hay lúc gọi đến nó mới tính toáncảm ơn anh vì câu trả lời !!
good job
@thangtd90 Em mò vào
Illuminate\Support\ServiceProvider
mà không thấyabstract protected function
nào tên làregister()
. Không biết là Laravel nó đã định nghĩa hàmregister()
này kiểu gì và ở đâu anh nhỉCòn nhiều cách để binding mà em
như dùng biến
$bindings
, biến$singletons
.Hoặc là em chỉ cần chạy hàm
boot
mà không cầnregister
Em tham khảo mấy cách viết Service Provider này https://laravel.com/docs/5.7/providers#writing-service-providers , nhiều cái không cần đến hàm
register
màQuả là kiến thức của em còn quá nhỏ bé, em luôn luôn dùng register để binding. Cảm ơn anh vì đã bỏ thời gian ra trả lời những thắc mắc vặt vãnh của em ạ (bow)
Nay em vừa mò lại package anh làm https://github.com/wataridori/chatwork-sdk. Thật bất ngờ khi anh k make bất cứ 1 Service Provider nào trong này luôn
Có tư tưởng hay lí do gì mà anh lai k làm như vậy không ạ 
À cái này đơn giản là package của anh là dành cho các project PHP nói chung, và bất kỳ framework nào cũng có thể dùng. Do đó nó không require bất kỳ package nào của Laravel, cũng như có các Service Provider dành cho một project Laravel rồi em
Bao giờ tên repo phải là
laravel-chatwork-sdk
thì em mới thấy có Service Provider trong đó được@thangtd90 Hợp lí anh ạ =)) Em cảm ơn anh
Em thấy a hau dùng thuật ngữ bootstrap, vậy bootstrap ở bài viết này là gì vậy ạ?
https://viblo.asia/p/mo-mam-mot-chut-ve-service-provider-trong-laravel-m68Z0MQXlkG#comment-RNZqqJwrLZ0
Đây bạn ạ
thanks anh ạ
Bài viết hay đấy! Nhưng nhiều người vẫn chưa hiểu không biết do tác giả không chia sẻ hết ý hay chưa thật sự hiểu sâu