Past tlustých Controllerů a Modelů: Rozdělení zodpovědností (SRP)

Problém "Fat Controller" a "Fat Model" v Laravelu

V raných fázích vývoje Laravel aplikací je lákavé vkládat veškerou aplikační logiku přímo do metod Controlleru. V jediném kontroleru pak často najdete validaci, autorizaci, orchestraci externích API, manipulaci s databázovými transakcemi, odesílání e-mailů a formátování odpovědi. Takový přístup se nazývá Fat Controller (tlustý kontroler).

Opačným extrémem bývá přesun veškeré logiky do Eloquent modelů – tzv. Fat Model. Modely pak obsahují desítky metod, které nesouvisejí s reprezentací datové entity, ale s orchestrací byznys procesů, generováním reportů nebo integrací třetích stran.

Oba tyto přístupy porušují první ze SOLID principů: Single Responsibility Principle (SRP) — třída by měla mít pouze jeden jediný důvod ke změně.

Jak vypadá rozdělení zodpovědností (Separation of Concerns)?

V moderním Laravelu 12 uplatňujeme čisté vrstvení:

1. HTTP Controller: Zodpovídá výhradně za HTTP protokol. Přijme HTTP požadavek (Request), provede základní validaci vstupů (ideálně přes FormRequest), zavolá příslušnou doménovou službu či Action třídu a transformuje výsledek do HTTP odpovědi (View, JsonResponse, RedirectResponse).
2. Service / Action vrstva: Zapouzdřuje doménovou logiku aplikace. Nezávisí na HTTP protokolu (může být volána z Controlleru, Artisan příkazu, fronty i testu).
3. Eloquent Model: Reprezentuje perzistentní data, relační vazby mezi tabulkami a nízkoúrovňové datové transformace (casts, mutátory).
4. Data Transfer Objects (DTO): Zajišťují bezpečný, typovaný a neměnný přenos dat mezi jednotlivými vrstvami.

Příklad z našeho projektu: Tenký CourseController

V našem vzdělávacím projektu agy-laravel důsledně uplatňujeme tenké kontrolery. Podívejme se na metodu switchProfile v CourseController.php:

public function switchProfile(
    Request $request,
    StudentProgressService $progressService,
): RedirectResponse {
    /** @var array{transfer_code: string} $validated */
    $validated = $request->validate([
        'transfer_code' => ['required', 'string', 'max:24'],
    ]);

    // Doménová logika vyhledání a validace kódu je delegována do služby
    $profile = $progressService->findByTransferCode($validated['transfer_code']);

    if ($profile === null) {
        return back()->with('error', 'Přenosový kód nebyl nalezen. Zkontroluj prosím jeho tvar.');
    }

    return redirect()
        ->route('course.index')
        ->with('success', 'Postup studenta byl úspěšně obnoven!')
        ->withCookie(cookie(
            name: StudentProgressService::COOKIE_NAME,
            value: $profile->token,
            minutes: 525600,
        ));
}

Všimněte si:

• Controller se nestará o to, jak se normalizuje kód studenta (odstranění mezer, velká písmena).
• Controller se nestará o to, ve kterém sloupci či tabulce je kód uložen.
• Metoda pouze převezme vstup, zavolá $progressService->findByTransferCode(...) a podle výsledku vrátí buď redirect s chybovou hláškou, nebo redirect s úspěchem a nastavením cookie.

Výhody pro testování a údržbu

1. Snadné jednotkové testy (Unit Testing): Servisní třídu StudentProgressService lze testovat izolovaně v Pest PHP bez nutnosti simulovat celý HTTP request/response cyklus.
2. Znovupoužitelnost: Stejnou servisní metodu můžeme zavolat z konzolového příkazu php artisan student:sync, z Livewire komponenty i z webhooku.
3. Přehlednost a čitelnost: Metody kontroleru mají 10–20 řádků a na první pohled je zřejmé, co je vstupem a jaký je výsledek.