Repository - доступ до даних

Repository відділяє бізнес-логіку від деталей доступу до даних за стабільним контрактом читання й запису.

Яку проблему вирішує

Коли сервіси звертаються до ORM напряму, бізнес-логіка прив'язується до Eloquent: запити розповзаються по коду, а підмінити джерело даних чи перевірити логіку без бази стає складно.

Як вирішує

Доступ до даних ховається за інтерфейсом-репозиторієм. Сервіс залежить від контракту, а конкретна реалізація (Eloquent, in-memory, API) підставляється через контейнер. У тестах дані легко підмінити фейком.

interface UserRepo
{
  public function byId(int $id): ?User;

  public function search(string $q);
}

class EloquentUserRepo implements UserRepo
{
  public function byId(int $id): ?User
  {
    return User::find($id);
  }

  public function search(string $q)
  {
    return User::query()
      ->where('name', 'like', "%$q%")
      ->get();
  }
}

class UserService
{
  public function __construct(private UserRepo $repo) {}

  public function show($id)
  {
    return $this->repo->byId($id);
  }
}

Де застосовувати

• Складні проєкти та інтеграції, де сервісам не можна залежати від ORM напряму.
• Коли джерело даних чи структура моделей може змінитися або потребує заміни у тестах.

Плюси та мінуси

• + Бізнес-логіка не залежить від ORM; дані легко підмінити фейком або in-memory.
• + Доступ до даних зосереджений за одним контрактом.
• − Додатковий шар і ризик дублювати API Eloquent.
• − У простих CRUD-екранах репозиторій зайвий - Eloquent уже сам по собі шар доступу до даних.