Facades provide a clean, static-like interface to classes in the service container — e.g. Cache::get(), DB::table(), Route::get(). They look like static method calls but actually proxy to underlying objects resolved from the container, combining static syntax convenience with the testability of dependency injection.
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);
A facade isn't a true static class — it forwards the call to a real object resolved from the service container. So you get clean, convenient syntax while the actual work is done by an injectable, mockable service.
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
Facades give a memorable, expressive API to Laravel's services — part of the framework's "elegant syntax."
// 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);
Because facades proxy to container objects, Laravel can swap in mocks for testing — Cache::shouldReceive(...), Mail::fake() — something genuine static methods don't allow.
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.)
Facades are a distinctive and pervasive Laravel feature — they appear throughout Laravel code (DB::, Cache::, Auth::, Route::, etc.), so understanding them is important for reading and writing Laravel applications.
The key insight is that facades look like static calls but actually proxy to objects resolved from the service container — this gives you the convenient, expressive static-like syntax that's part of Laravel's appeal, while preserving the benefits of dependency injection underneath (the real work is done by injectable, mockable services).
Crucially, this means facades are testable despite their static appearance: Laravel can swap in mocks (Cache::shouldReceive(), Mail::fake()) — something impossible with true static methods, which are notoriously hard to test.
Understanding how facades work (the container proxying), the common ones, their testability, and the trade-off with explicit dependency injection (facades for concise access vs constructor injection for explicit, clear dependencies — both valid, resolving from the same container) is important knowledge for working effectively with Laravel and for making informed architectural choices.
Since facades are one of Laravel's most recognizable features and are used constantly, demystifying them (they're not magic statics but container proxies) and knowing when to use them versus dependency injection reflects solid understanding of the framework's design and helps you write clean, testable Laravel code.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate