Facades bieden een schone, statische-achtige interface voor klassen in de service container — bijv. Cache::get(), DB::table(), Route::get(). Ze zien er uit als statische methodecalls, maar proxyen eigenlijk naar onderliggende objecten die uit de container worden opgelost, waarbij statische syntaxisgemak wordt gecombineerd met de testbaarheid van 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);
Een facade is geen echte statische klasse — het stuurt de call door naar een echt object dat uit de service container wordt opgelost. Dus je krijgt schone, handige syntaxis terwijl het eigenlijke werk wordt gedaan door een injecteerbare, mockbare 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 bieden een onvergetelijk, expressief API voor Laravel's services — onderdeel van de "elegante syntaxis" van het framework.
// 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);
Omdat facades proxyen naar containerobjecten, kan Laravel mocks voor testen inwisselen — Cache::shouldReceive(...), Mail::fake() — iets wat echte statische methoden niet toestaan.
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 zijn een onderscheidend en alomtegenwoordig Laravel-feature — ze verschijnen overal in Laravel-code (DB::, Cache::, Auth::, Route::, enz.), dus het begrijpen ervan is belangrijk voor het lezen en schrijven van Laravel-applicaties.
Het belangrijkste inzicht is dat facades er uitzien als statische calls, maar eigenlijk proxyen naar objecten die uit de service container worden opgelost — dit geeft je de handige, expressieve statische-achtige syntaxis die deel uitmaakt van Laravel's aantrekkingskracht, terwijl je de voordelen van dependency injection bewaart (het eigenlijke werk wordt gedaan door injecteerbare, mockbare services).
Cruciaal is dat dit betekent dat facades testbaar zijn ondanks hun statische verschijning: Laravel kan mocks inwisselen (Cache::shouldReceive(), Mail::fake()) — iets wat onmogelijk is met echte statische methoden, die notoir moeilijk te testen zijn.
Begrijpen hoe facades werken (het containerproxying), de veel voorkomende, hun testbaarheid, en de trade-off met expliciete dependency injection (facades voor beknopt gebruik vs constructorinjectie voor expliciete, duidelijke afhankelijkheden — beide geldig, opgelost vanuit dezelfde container) is belangrijke kennis voor effectief werken met Laravel en voor bewuste architectuurbeslissingen.
Omdat facades een van Laravel's meest herkenbare features zijn en constant worden gebruikt, het demystificeren ervan (het zijn geen magische statics, maar containerproxies) en weten wanneer je ze gebruikt versus dependency injection weerspiegelt solide kennis van het ontwerp van het framework en helpt je schone, testbare Laravel-code te schrijven.