Laravel Beauty: Tìm hiểu về Service container
Mở đầu
Trong bài viết lần trước, mình đã giới thiệu qua về Laravel, cũng như một vài
Best Practices mà mình hay sử dụng. Từ bài viết này, mình sẽ tập trung giới thiệu và giải thích về những thành phần core của Laravel Framework, hy vọng có thể giúp các bạn hiểu hơn về cách mà Laravel hoạt động.
Best Practices mà mình hay sử dụng. Từ bài viết này, mình sẽ tập trung giới thiệu và giải thích về những thành phần core của Laravel Framework, hy vọng có thể giúp các bạn hiểu hơn về cách mà Laravel hoạt động.
Đầu tiên sẽ là về một thành phần được coi là "trái tim" của Laravel, Service Container, thứ mà có thể các bạn đang dùng rất nhiều nhưng lại không biết là đang dùng ở đâu ^^!
Nếu các bạn đã từng làm việc với Laravel 4.2 mà chưa tìm hiểu nhiều về Laravel 5, thì bạn sẽ thấy khái niệm Service Container rất là mới mẻ. Thế nhưng thực chất nó đã tồn tại từ trước đó rồi, ở phiên bản 4.2 đổ về trước thì nó được người ta gọi dưới cái tên "Inversion of Control Container (IoC Container)". Nếu các bạn để ý thì từ phiên bản 5, trên document của Laravel, phần giới thiệu về IoC Container biến mất, và thay vào đó là Service Container.
Do đó, trước tiên hãy nói một chút về Inversion of Control nhé.
Dependency Injection và Inversion of Control
Cũng có ý kiến cho rằng Inversion of Control và Dependency Injection là một, và chúng chỉ là 2 cái tên được dùng cho một mục đích. Tuy nhiên, phần nhiều thì cho rằng Dependency Injection là một phần nhỏ của Inversion of Control, và nó là một trong những giải pháp để thực hiện Inversion of Control. Nhìn chung ta có thể hiểu đơn giản như sau:
- Dependency Injection: Mình đã từng đề cập ở bài viết trước.
Nếu một Class A hoạt động phụ thuộc vào một vài Class khác, thì thay vì khởi tạo các instance của các Class kia bên trong Class A, ta sẽ inject những instance đó vào thông qua constructor hay setter. Những instance của các Class mà Class A cần để hoạt động đó được gọi là dependency.
Ví dụ:
class Monitor {}
class Keyboard {}
class Computer
{
protected $monitor;
protected $keyboard;
public function __construct($monitor, $keyboard)
{
$this->monitor = $monitor;
$this->keyboard = $keyboard;
}
}
$computer = new Computer(new Monitor(), new Keyboard());
Như ở ví dụ trên ta có thể thấy class
Computer
cần các dependency là instance của Monitor
và Keyboard
. Thay vì khởi tạo các dependency này bên trong constructor của class Computer
, ta sẽ inject chúng vào khi gọi new Computer
.- Inversion of Control: Dưới đây là định nghĩa về IoC trên Wikipedia:
In software engineering, inversion of control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the reusable code that calls into the custom, or task-specific, code.
Trông có vẻ lằng nhằng và khó hiểu phải không? IoC là một kỹ thuật trong lập trình làm "đảo ngược" flow của những xử lý truyền thống. Bình thường thì đoạn xử lý logic của ta sẽ gọi đến những class, library mà nó cần dùng, thế nhưng, với IoC thì ta sẽ gửi cho những đoạn xử lý logic đó những thứ mà nó cần. Hay nói cách khác: Đừng cố gọi khắp nơi để tạo ra những thứ mà bạn cần (dependency), chúng tôi sẽ đưa chúng cho bạn khi chúng tôi cần đến bạn!
Với IoC thì các sự phụ thuộc sẽ được ghép vào các đối tượng tương ứng tại thời điểm run time thay vì compile time.
Nếu bạn vẫn chưa hiểu rõ về IoC thì ta hãy xem qua một ví dụ sau đây:
// With IoC
// Đầu tiên, ta đăng ký với IoC Container
IoC::register('computer', function() {
$keyboard = new Keyboard();
$monitor = new Monitor();
$computer = new Computer($monitor, $keyboard);
return $computer;
});
// Lấy ra một computer instance với dependency đã được inject
$photo = IoC::resolve('computer');
// Without IoC
$keyboard = new Keyboard();
$monitor = new Monitor();
$computer = new Computer($monitor, $keyboard);
Như ta thấy thì khi cần khởi tạo một instance của
Computer
, thay vì khởi tạo một cách thông thường bằng từ khóa new
rồi truyền các dependency vào cho nó thông qua constructor, thì với IoC, ta sẽ lấy ra khỏi Container bằng hàm resolve
, các xử lý tạo dependency cũng như đưa dependency vào trong class cần khởi tạo đều được thực hiện trong hàm callback mà ta đã register với IoC Container.
Với mô hình này thì ta có thể khởi tạo
Computer
bất cứ khi nào mà không cần phải nhớ xem nó cần những dependency gì. Khi bạn cần thêm module mới cho Computer
thì chỉ cần sửa lại hàm callback mà ta đăng ký với IoC Container là xong.
Thật là tuyệt vời là Laravel support IoC out of the box, chúng ta chỉ việc sử dụng.
Laravel Service Container
Như đã nói ở phần đầu, IoC Container ở phiên bản Laravel 4.2 đã được đổi tên lại thành Service Container ở phiên bản 5, với nhiều tính năng mới, tiện dụng hơn được thêm vào. Nhưng nhìn chung thì tư tưởng và cách hoạt động của nó không thay đổi. Service Container vẫn là một nơi quản lý class dependency và thực hiện dependency injection.
Bind và Resolve
Laravel sử dụng hai khái niệm
Chẳng hạn như ta có một ví dụ về cách
bind
để chỉ việc đăng ký một class hay interface với Container, và resolve
để lấy ra instance từ Container.Chẳng hạn như ta có một ví dụ về cách
bind
cũng như cách resolve
như sau:// Binding
\App::bind('computer', function() {
$keyboard = new Keyboard();
$monitor = new Monitor();
$computer = new Computer($monitor, $keyboard);
return $computer;
}
// Resolving.
\App::make('computer');
app('computer');
app()->make('computer');
app()['computer']
// Bạn có thấy có quá nhiều cách để bind và resolve không :D
// Hãy khoan nói về chuyện đó vội.
// Những bài sau mình sẽ giải thích kỹ càng về cách thức hoạt động của chúng.
Giống như một ví dụ ở phần trước, ta
bind
vào Container bằng một callback có xử lý khởi tạo, rồi dùng make
để lấy ra, đó là một cách dùng thường thấy. Tuy nhiên ví dụ sau sẽ cho bạn thấy được Service Container của Laravel mạnh mẽ đến thế nào :Dclass Computer
{
public $monitor;
public $keyboard;
public function __construct(Monitor $monitor, Keyboard $keyboard)
{
$this->monitor = $monitor;
$this->keyboard = $keyboard;
}
}
$computer = app('Computer');
// Hoặc
app()->bind('computer', 'Computer');
$computer = app('computer');
Như bạn thấy, ta không cần phải truyền bất cứ callback nào vào hàm
bind
cả. Thậm chí ta còn có thể gọi thẳng app('Computer')
để khởi tạo ra một instance của Computer
mà không cần bind gì hết, không cần khởi tạo dependency, không cần inject cái gì cả!
Hãy cùng phân tích xem Service Container thực hiện phép màu đó như thế nào nhé.
- Trước tiên, hãy để ý vào constructor của class
Computer
. Ở đây ta đã type-hint cho những dependency được truyền vào. Cụ thể$monitor
là một instance của classMonitor
, còn$keyboard
là một instance của classKeyboard
. - Khi ta gọi
app()->bind('computer', 'Computer');
thì tức là ta đã register cho một cái instance của classComputer
với cái têncomputer
. Và ta có thể resolve ra instance từ class đó bằngapp('computer')
. - Khi ta gọi
app('Computer')
thì trước tiên Laravel sẽ kiểm tra xem đã có cái gì được bind vào Container dưới tênComputer
hay chưa. Nếu chưa thì nó sẽ coiComputer
là tên class và tiến hành resolve ra instance từ classComputer
. - Quá trình tạo ra instance được tiến hành như sau: Container trước tiên sẽ kiểm tra thấy
Computer
cần 2 dependency là$monitor
và$keyboard
, và do ta đã type-hint cho 2 dependency này nên Service Container sẽ hiểu là cần phải lấy ra 2 dependency đó từ đâu. Service Container tiến hành resolve ra 2 instance củaMonitor
vàKeyboard
(quá trình resolve được tiến hành tương tự như đang resolve raComputer
), rồi inject nó vàoComputer
thông qua constructor injection. Và thế là cuối cùng ta sẽ có được một instance củaComputer
. - Chú ý rằng Service Container sẽ ưu tiên những gì được bind vào nó hơn. Tức là nếu bạn có câu lệnh
app()->bind('Computer', function(){return 'thang';});
thì khi resolveComputer
nó sẽ ra string'thang'
thay vì ra instance của classComputer
Một trong những điểm yếu của dependency injection đó là người lập trình sẽ gặp nhiều khó khăn khi các dependency của họ phụ thuộc tầng tầng lớp lớp vào nhau. Như ở ví dụ trên thì
Computer
có dependency là Monitor
và Keyboard
. Nhưng điều gì sẽ xảy ra nếu Monitor
của bạn lại có vài ba cái dependency. Và những dependency đó lại có vài ba cái dependency khác nữa. Bạn sẽ phải chuẩn bị hết những dependency đó để tạo ra computer. Tuy nhiên với Service Container thì mọi thứ dễ chịu hơn nhiều. Nếu dependency của class của bạn cần những dependency khác, nó sẽ có khả năng tự động inject hết cho bạn.Singleton binding, Instance binding, Interface binding và hơn thế nữa
Không chỉ hỗ trợ bind theo closure, hay tên class như đã trình bày ở trên, Service Container của Laravel còn hỗ trợ nhiều điều tuyệt vời hơn nữa :D
- Singleton binding: Như tên gọi của nó thì instance sẽ chỉ được resolve một lần, những lần gọi tiếp theo sẽ không tạo ra instance mới mà chỉ trả về instance đã được resolve từ trước
app()->singleton('now', function() {return time();});
app('now') === app('now'); // true
- Instance binding: Cũng gần giống với Singleton Binding. Bạn có một instance và bạn bind nó vào Service Container. Mỗi lần lấy ra bạn sẽ nhận lại được instance đó.
$now = time();
app()->instance('now', $now);
$now === app('now'); // true
- Interface binding: Như đã trình bày ở trên thì bạn có thể bind một Class dưới một cái tên bất kỳ. Và điều gì sẽ xảy ra nến cái tên đó là một Interface. Vâng nếu bạn bind một Interface với một Implementation của nó thì bạn sẽ có thể type-hint được Interface đó. Hãy cùng xem ví dụ dưới đây
class MailerImplementation implements MailerInterface {}
// Binding Interface với một Implementation của nó
app()->bind('MailerInterface', 'MailerImplementation');
// Trong constructor của một class nào đó ta có thể type-hint theo interface
public function __construct(MailerInterface $mailer)
{
$this->mailer = $mailer;
}
Trong ví dụ trên, khi mà một instance của class được resolve bằng Service Container thì
Nhưng bạn có thắc mắc là tại sao lại cần binding một Interface với một Implementation để làm gì không?
Tại sao lại cần phải type-hint Interface làm gì, sao ta không dùng thẳng tên class là implementation của Interface đó?
Câu trả lời là với việc type-hint Interface thì ta có thể có được sự linh hoạt trong việc thay đổi các Implementation mà mình muốn, hay sử dụng một Implementation mà mình viết thay vì cái mặc địch của Laravel mà không gây ảnh hưởng gì đến Framework hay service của mình. Đó là nguyên tắc "program to an interface, not an implementation"!
Chẳng hạn như bạn cần viết một package có chức sử dụng năng gửi mail. Hay nói cách khác bạn sẽ cần một class có dependency là một class gửi mail nào đó, giả sử là
$mailer
cũng sẽ được resolve ra, và nó sẽ là một instance của MailerImplementation
. Trong Laravel bạn sẽ gặp nhiều những trường hợp như trên khi sử dụng Contracts. Về bản chất thì Contracts chỉ đơn giản là những Interface, và khi bạn resolve hay type-hint chúng ở constructor hay methods thì sẽ nhận được Implementation tương ứng đã được đăng ký với Service Container. Chúng ta sẽ còn nhắc lại nhiều hơn về khái niệm này trong những bài sau ^^.Nhưng bạn có thắc mắc là tại sao lại cần binding một Interface với một Implementation để làm gì không?
Tại sao lại cần phải type-hint Interface làm gì, sao ta không dùng thẳng tên class là implementation của Interface đó?
Câu trả lời là với việc type-hint Interface thì ta có thể có được sự linh hoạt trong việc thay đổi các Implementation mà mình muốn, hay sử dụng một Implementation mà mình viết thay vì cái mặc địch của Laravel mà không gây ảnh hưởng gì đến Framework hay service của mình. Đó là nguyên tắc "program to an interface, not an implementation"!
Chẳng hạn như bạn cần viết một package có chức sử dụng năng gửi mail. Hay nói cách khác bạn sẽ cần một class có dependency là một class gửi mail nào đó, giả sử là
MailerImplentation
chẳng hạn. Nếu bạn sử dụng dependency injection thông qua constructor với type-hint là MailerImplentation
thì class của bạn sẽ hoàn toàn bị phụ thuộc vào MailerImplentation
đó và không thể thay đổi được. Thay vào đó bạn nên để dependency của class của mình là MailerInterface
, khi đó thì bất kỳ class nào có implement MailerInterface
đều có thể được inject vào và sử dụng trong class của bạn. Như vậy thì trong service chỉ cần có một implementation của MailerInterface
là package của bạn sẽ có thể hoạt động, bạn không cần biết implementation đó là gì, là mặc địch hay là do người khác viết.- Contextual Binding giúp bạn giải quyết được vấn đề sử dụng nhiều Implementation trong service của mình. Chẳng hạn như bạn có đến 2, 3 class là implementation của một Interface. Tuy nhiên trong một trường hợp bạn cần inject implementation này và trong trường hợp khác bạn lại cần implementation khác, khi đó bạn sẽ cần đến Contextual Binding. Ngoài ra bạn còn có thể sử dụng tag để gom một lúc nhiều thứ vào làm một, để lúc resolve được dễ dàng hơn.
// Tag
app()->tag(['Foo', 'Bar'], 'example');
// Resolve ra một mảng gồm các instance của Foo và Bar
app()->tagged('example');
Service Container everywhere
Service Container là thành phần trung tâm của Laravel, và có thể bạn không để ý nhưng nó đang được sử dụng ở mọi ngóc ngách trong project của bạn đấy. Bạn có còn nhớ trong bài viết lần trước, phần đề cập về Dependency Injectionmình đã từng giới thiệu một ví dụ như thế này không:
class UserController extends Controller
{
public function update(\Illuminate\Http\Request $request, $id)
{
$all = $request->all();
}
}
Đó là một ví dụ về method injection, tức inject dependency vào bên trong method của controller. Sở dĩ Laravel có thể giúp chúng ta thực hiện được việc đó là bởi vì nó sử dụng Service Container để resolve mọi controller. Mà đã dùng Service Container rồi thì như đã giải thích ở trên, bạn chỉ cần type-hint, và bạn sẽ có instance tương ứng :D
Không chỉ có Controller, mà hầu hết các phần quan trọng khác của Laravel như Middleware, Listener, Queue ... đều được resolve từ Service Container. Điều đó cũng có nghĩa là bạn có thể thực hiện dependency injection một cách dễ dàng trên chúng.
Lời kết
Trên document chính thức của Laravel, có một đoạn giới thiệu về Service Container như sau:
A deep understanding of the Laravel service container is essential to building a powerful, large application, as well as for contributing to the Laravel core itself.
Tạm dịch là "Sự hiểu biết sâu sắc về Laravel Service Container là điều thiết yếu để xây dựng một application lớn và mạnh mẽ, cũng như để đóng góp (contrubute) cho Laravel Core".
Nhìn chung, để có thể tìm hiểu sâu về Laravel thì Service Container là một khái niệm mà bạn không thể không nắm vững. Hy vọng bài viết này có thể giúp ích nhiều cho bạn.
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 xoay quanh Service Container như Service Providers, Contracts hay Facades sắp tới ^^!
Nguồn: https://viblo.asia
Comments
Post a Comment