Repository Pattern v Laravelu

1. Jak to vypadá běžně (The "Fat Controller" Way)

Většina začátečníků a menších projektů píše logiku přímo do controlleru. Je to rychlé, ale časem se z toho stává noční můra pro testování a údržbu.

Příklad v Controlleru:

public function index()
{
    // Query logika je celá v controlleru
    $users = User::where('active', true)
                 ->orderBy('last_login', 'desc')
                 ->take(10)
                 ->get();

    return view('users.index', compact('users'));
}

2. Jak to vypadá s Repository Patternem

S tímto vzorem vytvoříme vrstvu mezi Eloquent modelem a controllerem. Controller se pak nestará o to, jak se data získávají, ale jen o to, co s nimi udělá.

Krok 1: Interface

interface UserRepositoryInterface {
    public function getActiveUsers(int $limit);
}

Krok 2: Implementace

class UserRepository implements UserRepositoryInterface {
    public function getActiveUsers(int $limit) {
        return User::where('active', true)
                   ->orderBy('last_login', 'desc')
                   ->take($limit)
                   ->get();
    }
}

Krok 3: Čistý Controller

Díky Dependency Injection Laravel automaticky do controlleru "přihraje" správnou implementaci.

class UserController extends Controller {
    protected $userRepository;

    public function __construct(UserRepositoryInterface $userRepository) {
        $this->userRepository = $userRepository;
    }

    public function index() {
        $users = $this->userRepository->getActiveUsers(10);
        return view('users.index', compact('users'));
    }
}

3. Hlavní výhody a nevýhody

Výhody:

• Znovupoužitelnost: Jednu metodu (např. pro získání aktivních uživatelů) definujete v Repository jednou a následně ji voláte z controllerů, API nebo konzolových příkazů. Nemusíte nikde kopírovat stejné Query dotazy.

• Snadné testování: Díky použití Interface můžete v unit testech skutečnou databázi snadno nahradit tzv. "mockem". Testování je pak rychlejší a nezávislé na stavu databáze.

• Single Responsibility: Dodržujete princip jedné odpovědnosti. Controller řeší pouze HTTP požadavky a vracení odpovědí, zatímco Repository se stará výhradně o logiku získávání dat.

• Čistší Controllery: Zbavíte se dlouhých řetězců Eloquent dotazů v controlleru, který se tak stává mnohem čitelnějším.

Nevýhody:

• Více souborů a kódu: Pro každý model musíte vytvořit Interface a jeho implementaci. U malých projektů to může působit jako zbytečná administrativa, která zpomaluje vývoj.

• Abstrakce nad abstrakcí: Eloquent sám o sobě implementuje vzor Active Record, který už určitou úroveň abstrakce nabízí. Repository je tak vlastně další vrstva nad již existující vrstvou.

• Komplexita pro začátečníky: Pro nové nebo juniorní vývojáře může být navigace v kódu, kde jsou data schovaná za interface, zpočátku složitější než přímé volání modelu.

Závěr: Má smysl Repository Pattern v roce 2025 používat?

Repository pattern v Laravelu není univerzální zákon, který musíte slepě následovat. Pokud vyvíjíte malý web, jednoduché MVP nebo projekt, kde se logika databáze téměř nemění, vystačíte si bohatě s Eloquent modely a případně s Local Scopes. Laravel je navržen tak, aby byl rychlý a efektivní, a není ostuda psát kód přímočaře.

Pokud ale stavíte komplexní enterprise aplikaci, kde hraje prim testovatelnost, udržitelná architektura a čistý kód (Clean Code), Repository pattern vám vrátí investovaný čas i s úroky. Pomůže vám udržet controllery štíhlé a zajistí, že se vaše byznys logika neutopí v SQL dotazech.