Laravel Beauty: Tìm hiểu về Service container

https://viblo.asia/p/laravel-beauty-tim-hieu-ve-service-container-3KbvZ1wLGmWB

Laravel Beauty: Tìm hiểu về Service container

Editors' Choice

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.
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

  • 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();
    }
}

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

PHPLaravelIoCService ContainerDependency Injectioninversion of control

All rights reserved

MỤC LỤC

BÀI VIẾT THUỘC SERIES

Laravel: The Beauty1. 2. 3. 4. 5.

CÁC TỔ CHỨC ĐƯỢC ĐỀ XUẤT

Bài viết liên quan

Các tính năng mới của laravel 5.5 (p1)Viet Anh5 phút đọc 346 0 00Laravel Beauty: Tìm hiểu về FacadeTran Duc Thang12 phút đọc 18799 50 2177Tìm hiểu về Service Container trong LaravelHoàng Nguyễn9 phút đọc 15740 27 1256Laravel Beauty: Tìm hiểu về ContractTran Duc Thang8 phút đọc 8274 23 1043Học Laravel: Service ContainerNgo Duy Son10 phút đọc 2760 15 111Kiến trúc hệ thống trên Laravel – phần 3Nguyễn Trung Thành8 phút đọc 3552 7 022Hierarchical Dependency Injectors trong Angular 4Vương Hưng9 phút đọc 2096 4 16Dependency Injection & PHP Reflection in LaravelNgáo7 phút đọc 1917 2 08SOLID Principles in RubyPham Xuan Bach10 phút đọc 497 2 16Các tính năng mới của laravel 5.5 (p1)Viet Anh5 phút đọc 346 0 00Laravel Beauty: Tìm hiểu về FacadeTran Duc Thang12 phút đọc 18799 50 2177Tìm hiểu về Service Container trong LaravelHoàng Nguyễn9 phút đọc 15740 27 1256Laravel Beauty: Tìm hiểu về ContractTran Duc Thang8 phút đọc 8274 23 1043Học Laravel: Service ContainerNgo Duy Son10 phút đọc 2760 15 111

Bài viết khác từ Tran Duc Thang

Một số Design Principles trong lập trình mà bạn nên biếtTran Duc Thang22 phút đọc 5691 42 267[Become A SuperUser] Filesystem Hierarchy StandardTran Duc Thang19 phút đọc 1090 14 244Bài toán các vị tướng Byzantine và ứng dụng trong BlockchainTran Duc Thang19 phút đọc 7096 50 1584[Become a SuperUser] Debian vs Redhat: Package Management SystemTran Duc Thang14 phút đọc 2065 19 1135[Become a SuperUser] Manage file permissions and ownershipTran Duc Thang30 phút đọc 401 4 015[Become A SuperUser] Find system filesTran Duc Thang9 phút đọc 232 3 219[Review Sách] Cracking the Coding Interview - 189 Programming Questions & SolutionsTran Duc Thang16 phút đọc 1314 6 129Tìm hiểu về giải thuật Chia để Trị (Divide and Conquer)Tran Duc Thang18 phút đọc 3110 10 019Tìm hiểu về giải thuật Đệ QuyTran Duc Thang22 phút đọc 8558 6 018Cùng ôn lại các khái niệm về Cấu trúc dữ liệu, Giải thuật, Độ phức tạp thuật toán.Tran Duc Thang19 phút đọc 3221 34 158Simple Rules to make your code Cleaner (Part 2)Tran Duc Thang22 phút đọc 862 4 212Simple Rules to make your code Cleaner (Part 1)Tran Duc Thang15 phút đọc 1133 9 019Một số Design Principles trong lập trình mà bạn nên biếtTran Duc Thang22 phút đọc 5691 42 267[Become A SuperUser] Filesystem Hierarchy StandardTran Duc Thang19 phút đọc 1090 14 244Bài toán các vị tướng Byzantine và ứng dụng trong BlockchainTran Duc Thang19 phút đọc 7096 50 1584[Become a SuperUser] Debian vs Redhat: Package Management SystemTran Duc Thang14 phút đọc 2065 19 1135[Become a SuperUser] Manage file permissions and ownershipTran Duc Thang30 phút đọc 401 4 015[Become A SuperUser] Find system filesTran Duc Thang9 phút đọc 232 3 219[Review Sách] Cracking the Coding Interview - 189 Programming Questions & SolutionsTran Duc Thang16 phút đọc 1314 6 129Tìm hiểu về giải thuật Chia để Trị (Divide and Conquer)Tran Duc Thang18 phút đọc 3110 10 019

Bình luận

Cảm ơn bạn về bài viết rất hay và hữu ích

Cảm ơn anh rất nhiều \(^_^)//

Bài viết rất hay. Tôi phải đăng ký để thank bài này!

@tdchien @thanhws @phuocnt (thankyou) các bạn.

Bên cạnh bài viết về Service Container này thì vẫn còn các bài về các thành phần khác của Laravel trong Serie Laravel Beauty, các bạn có thể tham khảo. Hy vọng có thể nhận được ý kiến đóng góp từ mọi người. (honho)

Rất hay vào rất dễ hiểu cám ơn anh! wasshoi

Yes, I think this post is very helpful :3 bài viết hay lắm a ơi!

(thankyou) anh! Nhờ anh mà em thấy Laravel đúng là rất "đẹp"!

Như bạn nói các class dependency ví dụ ở trên như Keyboard hay Monitor sẽ được tự động inject để tiến tới resolve ra một instance của Computer cuối cùng. Đó là trong trường hợp các class kia không có tham số khởi tạo hoặc có tham số là object, còn nếu tham số của nó là Array, String, Int thì sao nhỉ, Service Container sẽ lấy các cái đó ở đâu ra để pass vào cho đảm bảo mọi thứ diễn ra tự động?

@imndnam Với trường hợp tham số đầu vào là parameter không xác định kiểu object, hay không có giá trị mặc định thì đương nhiên Service Container sẽ không thể biết cách để mà resolve ra instance cho bạn.

Nếu bạn vẫn muốn mọi thứ diễn ra tự động thì bạn có thể sử dụng hàm bind để dạy cho Service Container cách resolve ra instance, hoặc đặt giá trị mặc định cho chúng.

Chẳng hạn như một class như sau thì sẽ không thể resolve tự động bằng Service Container

class Test
{
    public $v;
    public function __construct($v)
    {
        $this->v = $v;
    }
}

Nhưng một class như sau thì có thể

class Test
{
    public $v;
    public function __construct($v = 'default value')
    {
        $this->v = $v;
    }
}

Bài viết rất chi tiết và dễ hiễu, chúc anh sức khỏe để có nhiều bài viết hay hơn nữa ^^

Cảm ơn bạn về bài viết rất hay này!

Bài viết rất hay và chi tiết, tuy nhiên mình vẫn chưa nắm hết được, chắc là do chưa làm thực tế nhiều, bookmarks lại chắc chắn sau này cần đến, big thanks !

Cảm ơn anh vì bài viết bổ ích

Bài viết rất hay, cảm ơn anh nhiều ^^ Tuy nhiên em vẫn còn mơ hồ, có lẽ phải thực hành nhiều mới hiểu sâu được.

Còn về câu hỏi của em thì instance thì em hiểu đơn giản là một thực thể của class.

vậy nó khác gì so vs object a

e có thắc mắc chổ "bind theo closure" a giải thích giúp e với ạ, nếu để MailerInterface $mailer trong hàm __construct khi chạy có lỗi a ơi ???

Bài viết rất hay, tks nhé !

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.

khúc này em ko hiểu lắm a có thể giải thích kỹ hơn giúp em không ạ!! thanks anh bài viết rất hay

Lần đầu tiên em gọi thì giá trị/object đó chưa tồn tại, Service Container sẽ tiến hành resolve nó ra, đồng thời lưu lại. Lần sau em gọi lại thì hệ thống sẽ lấy ra đúng giá trị/object đó để trả lại cho em mà sẽ không tiến hành tạo ra giá trị/object mới.

Như trong ví dụ ở bài viết thì em có thể khai báo singleton binding như sau

app()->singleton('now', function() {return time();});

À e cũng hiểu về lý thuyết rồi ạ, anh có thể thêm 1 ví dụ nhỏ để e dễ hình dung trong dự án thực tế không anh? Em cám ơn a

Nếu mình đã binding vào từ trước thì sẽ lấy trực tiếp từ binding ra, còn nếu không binding gì thì đơn giản là Service Container sẽ cố gắng khởi tạo một instance mới cho em. Đương nhiên lúc này giả sử để khởi tạo một instance $keyboard cần các dependencies khác thì Service Container sẽ lại tiếp tục phải resolve ra những dependencies đó trước để truyền vào.

lằng tờ ngoằng thật, đang quen kiểu đọc code gặp thằng hàm này thì biết nó viết ở đâu, còn ông này thì ếu biết tìm nó ở chỗ nào luôn

Cảm ơn bạn, bài viết thực sự rất hữu ích với mình

OK

Bài viết rất hay, tks anh

PreviousThe Repository Design PatternNextLaravel Beauty: Tìm hiểu về Service Provider

Last updated