Facade menyediakan antara muka seakan-statik yang bersih kepada kelas dalam service container — cth. Cache::get(), DB::table(), Route::get(). Ia kelihatan seperti panggilan method statik tetapi sebenarnya menjadi proksi kepada objek asas yang diselesaikan daripada container, menggabungkan kemudahan sintaks statik dengan kebolehujian dependency injection.
Facade kelihatan statik tetapi sebenarnya tidak
use Illuminate\Support\Facades\Cache;
Cache::put('key', 'value', 60); // looks like a static call...
Cache::get('key');
// ...but under the hood it proxies to a container-resolved cache instance.
// Equivalent to: app('cache')->put('key', 'value', 60);
Sebuah facade bukanlah kelas statik sebenar — ia memajukan panggilan kepada objek sebenar yang diselesaikan daripada service container. Jadi anda mendapat sintaks yang bersih dan mudah sementara kerja sebenar dilakukan oleh perkhidmatan yang boleh disuntik dan boleh dimock.
Facade lazim
DB::table('users')->get(); // database
Cache::remember('stats', 60, fn() => compute()); // caching
Auth::user(); // authentication
Route::get('/', ...); // routing
Log::info('message'); // logging
Storage::put('file.txt', $content); // filesystem
Mail::to($user)->send(new Welcome()); // mail
Validator::make($data, $rules); // validation
Facade memberikan API yang mudah diingat dan ekspresif kepada perkhidmatan Laravel — sebahagian daripada "sintaks elegan" framework ini.
Facade boleh diuji (tidak seperti statik sebenar)
// you can MOCK a facade in tests (impossible with true static methods)
Cache::shouldReceive('get')->with('key')->andReturn('value');
Mail::fake(); // assert mail was sent without sending it
Mail::assertSent(WelcomeEmail::class);
Kerana facade menjadi proksi kepada objek container, Laravel boleh menggantikan mock untuk pengujian — Cache::shouldReceive(...), Mail::fake() — sesuatu yang method statik sebenar tidak benarkan.
Facade berbanding dependency injection
Facade → convenient static-like syntax (Cache::get()), great for quick access
DI (constructor injection) → explicit dependencies, clearer for testing/coupling
→ Both resolve from the container; facades are sugar. Use DI when you want explicit
dependencies; facades for concise access. (Some prefer DI for clarity.)
Mengapa ia penting
Facade ialah ciri Laravel yang tersendiri dan menyeluruh — ia muncul di seluruh kod Laravel (DB::, Cache::, Auth::, Route::, dll.), jadi memahaminya adalah penting untuk membaca dan menulis aplikasi Laravel.
Wawasan utama ialah facade kelihatan seperti panggilan statik tetapi sebenarnya menjadi proksi kepada objek yang diselesaikan daripada service container — ini memberikan anda sintaks seakan-statik yang mudah dan ekspresif yang merupakan sebahagian daripada tarikan Laravel, sementara mengekalkan manfaat dependency injection di bawahnya (kerja sebenar dilakukan oleh perkhidmatan yang boleh disuntik dan boleh dimock).
Yang penting, ini bermakna facade boleh diuji walaupun penampilannya statik: Laravel boleh menggantikan mock (Cache::shouldReceive(), Mail::fake()) — sesuatu yang mustahil dengan method statik sebenar, yang terkenal sukar untuk diuji.
Memahami cara facade berfungsi (proksi container), yang lazim, kebolehujiannya, dan pertukaran dengan dependency injection eksplisit (facade untuk akses ringkas berbanding constructor injection untuk dependency yang eksplisit dan jelas — kedua-duanya sah, diselesaikan daripada container yang sama) ialah pengetahuan penting untuk bekerja dengan berkesan dengan Laravel dan untuk membuat pilihan seni bina yang berinformasi.
Memandangkan facade ialah salah satu ciri Laravel yang paling mudah dikenali dan digunakan secara berterusan, menjelaskannya (ia bukan statik ajaib tetapi proksi container) dan mengetahui bila hendak menggunakannya berbanding dependency injection mencerminkan pemahaman yang kukuh tentang reka bentuk framework dan membantu anda menulis kod Laravel yang bersih dan boleh diuji.