Kiến trúc Laravel (Deep Dive): Hiểu để Làm chủ

Trả lời: Mọi request đều bắt đầu từ file public/index.php. Nó load autoloader và khởi tạo instance của ứng dụng.

Trả lời: Nó là một cái “kho” chứa tất cả các lớp (classes) và cách để tạo ra chúng, hỗ trợ Dependency Injection tự động.

Trả lời: Facades cung cấp một giao diện “tĩnh” (static) cho các lớp có sẵn trong Service Container, giúp cú pháp ngắn gọn hơn.

Trả lời: Dùng để cấu hình (bootstrap) ứng dụng, ví dụ: đăng ký các binding vào container hoặc khai báo các route.

Trả lời: Là các bộ lọc nằm giữa Request và Controller, dùng để kiểm tra Auth, log, hoặc thay đổi request/response.

Trả lời: Web Kernel xử lý các request HTTP từ trình duyệt. Console Kernel xử lý các câu lệnh chạy qua dòng lệnh (CLI).

Trả lời: Là một class thực hiện một nhiệm vụ cụ thể (như gửi mail, thanh toán) được quản lý bởi Service Container.

Trả lời: Lưu trữ các cấu hình nhạy cảm và thay đổi theo môi trường (như DB credentials) để không phải hardcode trong code.

Trả lời: Để lưu trữ các file cache của framework (config, routes, services) giúp ứng dụng khởi động nhanh hơn.

Trả lời: Là hành động đăng ký một class hoặc một closure vào container để Laravel biết cách tạo ra instance của nó sau này.

Trả lời: Tăng tính linh hoạt và dễ test. Bạn có thể thay đổi implementation (ví dụ từ Mailgun sang Postmark) bằng cách sửa binding trong Service Provider mà không cần chạm vào logic nghiệp vụ.

Trả lời: Laravel 11 tinh gọn hóa cấu trúc. File này giờ đây quản lý cả Routing, Middleware, và Exception Handling, thay thế cho các class Kernel cồng kềnh trước đây.

Trả lời:

• Singleton: Container chỉ tạo object đó một lần duy nhất và dùng lại.
• Bind (Transient): Mỗi lần yêu cầu sẽ tạo ra một object hoàn toàn mới.

Trả lời:

1. Gọi register() của tất cả providers. 2. Sau đó mới gọi boot() của tất cả providers. Đảm bảo mọi service đã được đăng ký trước khi sử dụng.

Trả lời: Dùng mảng các closure. Request đi qua từng middleware qua hàm $next($request). Kết quả trả về là một Response đi ngược lại qua các lớp middleware.

Trả lời: Dùng hàm app()->make(ClassName::class) hoặc helper resolve(ClassName::class).

Trả lời: Map một Interface tới một Class cụ thể. Giúp code linh hoạt: khi muốn đổi thư viện gửi mail, chỉ cần sửa dòng bind trong Provider mà không cần sửa code nghiệp vụ.

Trả lời: Cho phép bạn chỉ định: Nếu Class A yêu cầu Interface X thì đưa cho Implementation 1, còn Class B yêu cầu Interface X thì đưa cho Implementation 2.

Trả lời: Là instance thực tế của class nằm trong Container mà Facade đó đang đại diện. Facade chỉ là một “lớp vỏ” trỏ tới Facade Root.

Trả lời: Đảm bảo các service quan trọng (như một SDK kết nối bên thứ 3) chỉ được khởi tạo 1 lần duy nhất trong suốt vòng đời của 1 request.

Trả lời: Dùng lệnh php artisan make:provider. Sau đó thêm tên class vào file bootstrap/providers.php (Laravel 11) hoặc config/app.php (Laravel cũ).

Trả lời: Giải quyết vấn đề “Hard-coded Dependencies”. Giúp class không cần quan tâm đến việc tạo ra các dependencies, từ đó dễ dàng bảo trì và mở rộng.

Trả lời: Class base Facade bắt sự kiện gọi static không tồn tại. Nó dùng getFacadeAccessor() để lấy key, resolve object từ Container, sau đó dùng call_user_func_array để thực thi method.

Trả lời: Laravel dùng ReflectionClass để phân tích constructor. Nó xem từng tham số có type-hint là gì, sau đó đệ quy gọi container để tạo các class đó trước khi truyền vào constructor của class chính.

Trả lời: Laravel lưu danh sách các service và provider tương ứng vào một file manifest. Provider chỉ được load vào bộ nhớ khi ứng dụng thực sự gọi tới một trong những service đó.

Trả lời: Dùng phương thức $this->app->extend(Service::class, function($service, $app) { ... }). Rất hữu ích để wrap thêm decorator hoặc cấu hình thêm cho service của thư viện.

Trả lời: Nó thực thi logic: array_reduce($pipes, $destination, $initial). Nó biến danh sách các class thành một chuỗi các closure lồng nhau.

Trả lời: Là việc bind một giá trị đơn giản (string, int) vào một tham số cụ thể của constructor, thay vì bind một Class object.

Trả lời: Cho phép “độ” thêm hàm vào class lúc runtime. Nó dùng __call để check xem method có nằm trong mảng $macros không và thực thi closure tương ứng.

Trả lời: Dùng $this->app->makeWith(ClassName::class, ['param' => $value]). Các tham số này sẽ được ưu tiên hơn các binding mặc định.

Trả lời: Đây là “Trái tim” của Laravel. Nó kế thừa Container và thực thi các interface của Framework, quản lý các đường dẫn (paths), môi trường (environment), và các bootstrappers.

Trả lời: Là khi một service đã được resolve nhưng bạn lại bind lại key đó vào container. Các class đã nhận instance cũ sẽ không tự cập nhật instance mới, gây sai lệch trạng thái.

Trả lời: Mỗi Plugin là một package có ServiceProvider. Dùng Discovery để tự động load. Plugin đăng ký các service vào Container kèm theo các “Tags”. Ứng dụng chính resolve các tags này để thực thi logic plugin.

Trả lời: Service Locator làm class phụ thuộc vào Container (Framework). DI giúp class hoàn toàn “sạch”, không biết gì về Framework, dễ dàng Unit Test và tái sử dụng ở bất cứ đâu.

Trả lời: Octane khởi động Application 1 lần và giữ trong RAM (Worker). Container không bị xóa sau mỗi request. Cần cực kỳ cẩn thận với “Stateless” và tránh lưu dữ liệu request vào các biến static/singleton.

Trả lời: Dùng một “TenantServiceProvider” chung để nhận diện tenant. Sau đó dùng instance của Application để đăng ký động (dynamically register) các providers cần thiết cho tenant đó tại runtime.

Trả lời: Tầng nghiệp vụ (Domain) chỉ dùng các Interface (Contracts). Tầng hạ tầng (Infrastructure) cung cấp Implementation. Container làm nhiệm vụ “hàn” 2 tầng này lại với nhau trong Service Provider.

Trả lời: Sử dụng các hook resolving, afterResolving. Khi một class cụ thể được resolve, tự động bắn ra một Event hoặc thực thi một logic “setup” nào đó mà class đó không cần biết.

Trả lời: bindIf chỉ thực hiện binding nếu key đó chưa tồn tại trong container. Rất quan trọng khi viết package để cho phép người dùng ghi đè (override) các binding mặc định của package.

Trả lời: Dùng php artisan optimize để cache manifest. Ưu tiên Singleton cho class đắt đỏ. Sử dụng Proxy class (Lazy Loading) nếu một service nặng chỉ thỉnh thoảng mới dùng tới.

Trả lời: Giống Singleton nhưng chỉ tồn tại trong phạm vi 1 request hoặc 1 job. Khi request kết thúc, instance bị hủy. Giúp tránh tràn bộ nhớ trong các môi trường như Octane.

Trả lời: Support chứa các helper dùng chung (Collection, Str) không phụ thuộc Framework. Foundation là khung xương của Framework. Điều này giúp các package có thể dùng Support mà không cần kéo theo toàn bộ Framework.

Xử lý: Cần can thiệp vào file public/index.php hoặc ghi đè (bind) lại instance request trong Container ngay từ giai đoạn sớm nhất của vòng đời.

Xử lý: 1. Tách phần dùng chung ra service thứ 3. 2. Dùng Interface thay vì Class cụ thể. 3. Dùng “Setter Injection” hoặc resolve thủ công trong method thay vì constructor.