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