---
title: "Repository - доступ до даних"
url: https://laravelukraine.com/blog/repository-dostup-do-danix
date: 2026-08-10
---

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

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

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

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

### Як вирішує

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

```php
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 уже сам по собі шар доступу до даних.