Facades tilbyder en ren, statisk-lignende grænseflade til klasser i service container'en — f.eks. Cache::get(), DB::table(), Route::get(). De ligner statiske metodekald, men fungerer faktisk som proxyer til underliggende objekter, der løses fra container'en, hvilket kombinerer den statiske syntaks' bekvemmelighed med testbarheden af 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);
En facade er ikke en ægte statisk klasse — den videresender kaldet til et rigtigt objekt, der løses fra service container'en. På den måde får du ren, bekvem syntaks, mens det faktiske arbejde udføres af en injicerbar, mokkbar 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 giver et uforglemeligt, ekspressivt API til Laravels services — en del af frameworkets "elegant syntaks".
// 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);
Fordi facades fungerer som proxyer til container-objekter, kan Laravel bytte dem ud med mocks til test — Cache::shouldReceive(...), Mail::fake() — noget som ægte statiske metoder ikke tillader.
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 er en karakteristisk og udbredt Laravel-funktion — de optræder overalt i Laravel-kode (DB::, Cache::, Auth::, Route:: osv.), så forståelse af dem er vigtig for at læse og skrive Laravel-applikationer.
Hovedindlægten er, at facades ligner statiske kald, men faktisk fungerer som proxyer til objekter, der løses fra service container'en — dette giver dig den bekvemme, ekspressive statisk-lignende syntaks, der er en del af Laravels appel, mens det bevarer fordelene ved dependency injection under overfladen (det faktiske arbejde udføres af injicerbare, mokkbare services).
Kritisk vigtig er det, at facades betyder, at de er testbare trods deres statiske udseende: Laravel kan bytte dem ud med mocks (Cache::shouldReceive(), Mail::fake()) — noget som er umuligt med ægte statiske metoder, som bekendt er vanskelige at teste.
At forstå, hvordan facades virker (container-proxying), de almindelige facades, deres testbarhed, og afvejningen med eksplicit dependency injection (facades for koncis adgang vs constructor injection for eksplicitte, klare dependencies — begge gyldig, løst fra samme container) er vigtig viden for effektivt arbejde med Laravel og for at træffe informerede arkitektoniske valg.
Da facades er en af Laravels mest genkendelige funktioner og bruges konstant, kan opklaringen af dem (de er ikke magiske statics, men container-proxyer) og viden om hvornår man skal bruge dem i forhold til dependency injection afspejle solid forståelse af frameworkets design og hjælper dig med at skrive ren, testbar Laravel-kode.