Các khái niệm trong NestJS

[KhoaTT (Ngo ngoc khoa)]

Chào mọi người, em đang học và làm việc với NestJS. Em đang ôn kiến thức để đi phỏng vấn mà gặp 1 vài khái niệm trong docs hướng dẫn hơi lan man (có thể là do em yếu tiếng anh nên k hiểu rõ). Đó là:

• provider là gì
• modules là gì
• dependency injection là gì

Những cái trên em đều làm được, nhưng lý thuyết thì k biết trả lời sao cho nó rõ nghĩa nhất. Mong mọi người giúp em với. Cảm ơn mọi người đã đọc. Chúc mọi người buổi tối tốt lành

[library (La biblioteca)]

Cậu thử trình bày cậu hiểu gì về nó trước được không? Bọn tớ sẽ sửa cho cậu

[KhoaTT (Ngo ngoc khoa)]

Dạ theo như em hiểu là

• Provider là 1 khái niệm cơ bản trong NestJS, các class cơ bản có thể được coi là provider như là services, repositories, … ý tưởng chính của nó có thể inject như dependency.

• Module là class được define với decorator là @Module, có nhiệm vụ đóng gói những logic liên quan của các chức năng cần triển khai 1 cách độc lập. Bao gồm 4 thành phần:
  – controllers: khởi tạo những controller đã define trong module
  – imports: imporrt các module khác hoặc lib
  – providers: khởi tạo các provider mà controller trong module sẽ sử dụng đến
  – exports: export proivder cho các module khác sử dụng

• Dependency Injection có nghĩa là:
  – Giảm sự phụ thuộc lẫn nhau giữa các module, có thể dễ dàng maintain và testing
  – Các module không giao tiếp trực tiếp với nhau mà thông qua interface. Module cấp thấp sẽ implement interface, module cấp cao sẽ gọi module cấp thấp.

Không biết như vậy ổn chưa vậy anh, nếu chưa ổn thì mong anh hướng dẫn và sửa giúp em với

[baoo (ㅤ)]

Topic này giải thích khá đầy đủ về depedency injection.

Xin ví dụ về Dependency injection (DI)

Xin chào, mình đọc định nghĩa về Dependency injection nhưng vẫn cảm thấy khó hiểu, nhờ các bác cho mình xin vài ví dụ thực tế với! thanks

Giải thích về Inversion of Control:

Giải thích về Dependency Injection và Inversion of Control

Series bài viết Dependency Injection và Inversion of Control gồm 3 phần: Định nghĩa Áp dụng DI vào code Viết DI Container. Áp dụng DI vào ASP.NET MVC Hôm trước, có vài bạn nhờ mình giải thích các khái niệm Dependency Injection, Inversion of Control. Vốn lười, mình định google một bài viết bằng tiếng Việt để quăng cho các bạn ấy. Ngặc một nỗi là mình chả tìm được bài nào cụ thể rõ ràng về Dependency Injection, chỉ có hướng dẫn sử dụng Unity, StructureMap. Một số bài viết hay thì lại toàn bằng …

[library (La biblioteca)]

Uhm, nghe mơ hồ nhỉ?

Tớ không phải chuyên gia về nestjs, nên tớ có đọc thử trên trang chủ của framework về các topic cậu đề cập sau khi đọc định nghĩa mà cậu đưa ra.
Về provider, tớ để ý thấy họ cũng đề cập giống cậu. Cơ mà, như cậu có thể thấy, provider trong nestjs là các class được tag decorator support trong nestjs common (như @Injectable, @Controller,…), với mục đích sử dụng tính năng tự động inject các phụ thuộc vào các class khác bởi Nest injector, và được quản lý bới Nest IoC container.
Tớ nghĩ cách giải thích này tốt hơn document của họ. “Fundamental concept” là thứ rất trừu tượng, “ý tưởng chính” cũng tương đối trừu tượng nốt. Nếu cậu có thể giải thích chi tiết hơn, cậu nên làm thế. Nếu không, cậu nên có ví dụ (đó là cách mà document đã làm).

Về module, cách giải thích của cậu ở đoạn đầu thì ổn. Module là cách tổ chức chương trình của NestJS. Cơ mà, 4 thành phần mà cậu đề cập chỉ là 4 thuộc tính mô tả 1 module mà @Module decorator nhận.
Cậu cũng có thể liên kết với provider ở trước để giải thích concept này, vì module liên hệ chặt chẽ với khái niệm provider.

Về DI, cậu đang nêu ra lợi ích của DI. Có lẽ, cậu thử đọc các reference mà @baoo đề cập, và thử giải thích lại theo ý hiểu của cậu xem.

Hope it helps!

[hungaya (Hung)]

Các đoạn khác thì bạn đúng rồi, bạn chỉ bị nhầm lẫn khúc này.

@KhoaTT

Các module không giao tiếp trực tiếp với nhau mà thông qua interface. Module cấp thấp sẽ implement interface, module cấp cao sẽ gọi module cấp thấp.

Module là nơi liên kết giữa interfaces và implementation (thông qua cơ chế DI). Implementation chỉ được thấy trong moduble, bên ngoài module không truy cập được, interfaces thì có hai loại

• Interface trong được thêm trong export để cho các module khác sử dụng.
• Interface sử dụng nội bộ trong module, trường hợp kích thước module lớn.

Về giao tiếp các modules, mỗi module đảm nhiệm business domain khác nhau, các module giao tiếp với nhau thông qua các interfaces được export. Ngoài ra, không có khái niệm DI giữa các modules với nhau.