Index

1. Laravel Beauty: Recipes & Best Practices
2. Laravel Beauty: Tìm hiểu về Service Container
3. Laravel Beauty: Tìm hiểu về Service Provider
4. Laravel Beauty: Tìm hiểu về Facade
5. Laravel Beauty: Tìm hiểu về Contract

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.

Đầ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 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

class 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 class Monitor, còn $keyboard là một instance của class Keyboard.
• Khi ta gọi app()->bind('computer', 'Computer'); thì tức là ta đã register cho một cái instance của class Computer với cái tên computer. Và ta có thể resolve ra instance từ class đó bằng app('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ên Computer hay chưa. Nếu chưa thì nó sẽ coi Computer là tên class và tiến hành resolve ra instance từ class Computer.
• 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ủa Monitor và Keyboard (quá trình resolve được tiến hành tương tự như đang resolve ra Computer), rồi inject nó vào Computer thông qua constructor injection. Và thế là cuối cùng ta sẽ có được một instance của Computer.
• 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 resolve Computer nó sẽ ra string 'thang' thay vì ra instance của class Computer

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

• 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ì $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 Injection mì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

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 ^^!