Cell Framework là một giải pháp ứng dụng tiến bộ dựa trên TypeScript, ưu tiên kiến trúc Serverless, hướng thành phần và độc lập với nền tảng. Để tận dụng tối đa sức mạnh của Cell, người phát triển cần nắm vững hai khái niệm trụ cột: Dependency Injection (DI - Tiêm phụ thuộc) và mô hình Component. Bài viết này sẽ phân tích chi tiết cách thức vận hành của cơ chế DI trong Cell, cách quản lý vòng đời thành phần, và các chiến lược thiết kế giúp ứng dụng Serverless đạt hiệu suất cao.

1. Cơ chế IoC Container và Quản lý Phụ thuộc

Nền tảng của Cell là Container (Bộ chứa), chịu trách nhiệm quản lý việc tạo lập, giải quyết và chèn phụ thuộc vào các thành phần trong ứng dụng. Thay vì开发者 phải khởi tạo đối tượng thủ công bằng từ khóa new, Container sẽ tự động xử lý quy trình này dựa trên các cấu hình đã đăng ký.

1.1 Khởi tạo và Cấu hình Container

Việc thiết lập môi trường chạy của Cell thường bắt đầu từ việc bootstrapping Container. Đoạn mã dưới đây minh họa cách khởi tạo một container động và đăng ký các module cốt lõi:

// core/bootstrap.ts
import { DynamicContainer, ServiceBootstrap } from '@cellbang/core';

export class ApplicationBootstrap {
  static initialize(modules: any[] = []): DynamicContainer {
    const context = new DynamicContainer();
    
    // Đăng ký chính container vào trong chính nó để hỗ trợ injection lồng nhau
    context.registerInstance(DynamicContainer, context);
    context.registerClass(ServiceBootstrap, ServiceBootstrap);
    
    // Nạp các module định nghĩa bởi người dùng
    modules.forEach(mod => context.install(mod));
    
    return context;
  }
}

Trong ví dụ này, DynamicContainer đóng vai trò là trung tâm điều phối. Việc đăng ký chính container làm một service cho phép các thành phần khác truy cập ngữ cảnh của hệ thống nếu cần thiết.

1.2 Các mức độ Phạm vi (Scope)

Cell cung cấp các chiến lược quản lý vòng đời đối tượng linh hoạt thông qua enum Scope, giúp tối ưu hóa tài nguyên đặc biệt trong môi trường Serverless:

• Singleton (Đơn thể): Chỉ có một thực thể duy nhất tồn tại trong suốt vòng đời của Container. Phù hợp cho các dịch vụ kết nối Database hoặc Cache.
• Request (Yêu cầu): Một thực thể mới được tạo ra cho mỗi yêu cầu xử lý (ví dụ: mỗi lần gọi API).
• Transient (Tạm thời): Mỗi lần yêu cầu injection sẽ tạo ra một thực thể mới hoàn toàn.

// common/scope-definition.ts
export enum LifecycleScope {
  Singleton = 'singleton',
  Request = 'request',
  Transient = 'transient'
}

2. Mô hình Component và Vòng đời

Trong Cell, một lớp (class) trở thành một thành phần có thể quản lý được thông qua decorator @Component. Cơ chế này cho phép framework quét, đăng ký và tự động wire (nối dây) các phụ thuộc.

2.1 Khai báo Component và Injection

Để khai báo một dịch vụ, ta sử dụng @Component kết hợp với @Inject trong constructor. Xem ví dụ về một dịch vụ xử lý thanh toán giả định:

// services/billing-service.ts
import { Component, Inject } from '@cellbang/core';

export const IBillingService = Symbol('IBillingService');

export interface IBillingService {
  processAmount(amount: number): Promise<boolean>;
}

@Component(IBillingService)
export class StripeBillingService implements IBillingService {
  private client: any;

  constructor(@Inject('Logger') private logger: any, @Inject('Config') private config: any) {
    this.client = this.initClient();
  }

  private initClient() {
    // Logic khởi tạo client
    return {};
  }

  async processAmount(amount: number): Promise<boolean> {
    this.logger.info(`Processing ${amount}`);
    return true;
  }
}

Lưu ý rằng ta nên phụ thuộc vào Interface (biểu tượng Symbol) thay vì lớp cụ thể để duy trì nguyên tắc đảo ngược phụ thuộc.

2.2 Hook Vòng đời

Cell cung cấp các hook @PostConstruct và @PreDestroy để thực thi logic tại các thời điểm then chốt:

@Component(ConnectionPool)
export class DatabaseConnection {
  private isConnected = false;

  @PostConstruct()
  async connect() {
    // Logic kết nối DB
    this.isConnected = true;
    console.log('Database connection established.');
  }

  @PreDestroy()
  async disconnect() {
    // Logic đóng kết nối
    this.isConnected = false;
    console.log('Database connection closed.');
  }
}

2.3 Giao tiếp qua Event Bus

Để giảm sự phụ thuộc trực tiếp giữa các module, Cell khuyến khích sử dụng Event Bus. Thay vì Service A gọi trực tiếp Service B, Service A phát đi một sự kiện và Service B lắng nghe sự kiện đó.

// components/user-sync.ts
@Component(UserSyncComponent)
export class UserSyncHandler {
  constructor(
    @Inject(EventBus) private bus: EventBus,
    @Inject(EmailService) private mailer: EmailService
  ) {
    // Lắng nghe sự kiện người dùng đăng ký
    this.bus.subscribe(UserRegisteredEvent, this.handleRegistration.bind(this));
  }

  private async handleRegistration(event: UserRegisteredEvent) {
    await this.mailer.sendWelcomeEmail(event.email);
  }
}

3. Chiến lược Injection Nâng cao

3.1 Tiêm dựa trên Tên (Named Injection)

Khi có nhiều lớp triển khai (implementation) cho cùng một interface, bạn có thể sử dụng @Named để phân biệt:

// Đăng ký trong module
[
  { provide: IStorage, name: 'Local', useClass: LocalDiskStorage },
  { provide: IStorage, name: 'Cloud', useClass: S3Storage }
]

// Sử dụng trong component
constructor(
  @Inject(IStorage) @Named('Cloud') private remoteStorage: IStorage
) {}

3.2 Tiêm giá trị cấu hình (@Value)

Decorator @Value cho phép tiêm các thông số cấu hình từ file môi trường vào thuộc tính của component:

@Component(ApiClient)
export class ExternalApiClient {
  constructor(
    @Value('services.api.endpoint') private endpoint: string,
    @Value('services.api.timeout', 3000) private timeout: number
  ) {}

  async fetchData() {
    // Sử dụng this.endpoint và this.timeout
  }
}

4. Các vấn đề thường gặp và Giải pháp

4.1 Phụ thuộc vòng (Circular Dependency)

Vấn đề này xảy ra khi Class A phụ thuộc vào B, và B lại phụ thuộc vào A. Trong Cell, cách giải quyết tốt nhất là tái cấu trúc code sử dụng Event Bus hoặc tách logic chung ra một Class thứ ba (Service C).

4.2 Quá tải Constructor

Nếu một component có quá nhiều tham số trong constructor (ví dụ: hơn 5 tham số), đây là dấu hiệu của việc vi phạm Nguyên tắc Trách nhiệm Đơn nhất (SRP). Giải pháp là nhóm các phụ thuộc liên quan thành các Module nhỏ hơn hoặc sử dụng các đối tượng cấu hình (Option Objects).

4.3 Lạm dụng Singleton

Mặc dù Singleton giúp tiết kiệm tài nguyên, nhưng sử dụng nó cho các thành phần chứa trạng thái (stateful) trong môi trường đa luồng hoặc Serverless có thể gây ra lỗi dữ liệu không đồng bộ. Chỉ sử dụng Singleton cho các dịch vụ không trạng thái (stateless) như utility functions hoặc connection pools đã được thread-safe.