What is the Repository pattern?

Question

IT Interview Practice · Accepted Answer

The **Repository** pattern abstracts **data access** behind a collection-like interface — separating business logic from how data is stored and retrieved. It decouples the application from data sources (databases, APIs), improving testability and maintainability.

## What the Repository pattern does

```text
REPOSITORY → an abstraction layer between business logic and DATA ACCESS:
  → provides a clean interface (like a collection: findById, save, delete, findAll)
  → HIDES how/where data is actually stored (database, API, cache, files)
  → business logic uses the repository, NOT the database directly
→ separate WHAT data operations from HOW they're implemented
```

## Example

```js
// repository interface — business logic depends on THIS, not the DB
class UserRepository {
  async findById(id) { /* query the database (hidden behind here) */ }
  async save(user) { /* insert/update */ }
  async findByEmail(email) { /* ... */ }
}
// business logic uses the repository, unaware of the data source
const user = await userRepository.findById(42);
// → swap the DB, or use a mock in tests, without changing business logic
```

## Benefits

```text
✓ DECOUPLING → business logic doesn't depend on data-access details (DB, ORM, API) →
  swap data sources without changing business logic
✓ TESTABILITY → use a MOCK/fake repository in tests (no real database needed)
✓ CENTRALIZED data access → query logic in one place (maintainable, consistent)
✓ CLEANER architecture → clear separation between domain/business logic and data
→ common in layered/clean architectures; works with DI
```

## Why it matters

Understanding the Repository pattern is valuable because it's a **common, practical pattern** for cleanly separating business logic from data access, so it's relevant design knowledge.

The Repository pattern abstracts data access behind a collection-like interface (findById, save, delete), **hiding how and where data is stored** so business logic uses the repository rather than the database directly.

Understanding what it does (providing a clean data-access interface that hides the actual storage, separating *what* data operations from *how* they're implemented) is the core knowledge.

Understanding the **benefits** is key: **decoupling** (business logic not depending on data-access details like the specific database, ORM, or API, so you can swap data sources without changing business logic — a valuable architectural benefit), **testability** (using mock/fake repositories in tests so no real database is needed — important for unit testing business logic), **centralized data access** (query logic in one place for maintainability and consistency), and **cleaner architecture** (clear separation between domain/business logic and data).

These benefits make the Repository pattern practically valuable for maintainable, testable applications.

Understanding that it's common in **layered/clean architectures** and works with dependency injection clarifies its place in modern architecture.

The Repository pattern is widely used because separating business logic from data access (for testability, maintainability, and flexibility) is a common, important need.

Since the Repository pattern is a common, practical pattern for cleanly separating business logic from data access (decoupling, testability, centralized data access, cleaner architecture) — a common, important need — and is central to layered/clean architectures, and since understanding what it does and its benefits is relevant for building maintainable applications, understanding the Repository pattern is valuable, practically-relevant design knowledge — a frequently-used pattern for separating business logic from data access, providing decoupling and testability, central to clean/layered architectures, and important design knowledge for building maintainable, testable applications with clean separation between logic and data.

What the Repository pattern does

Example

Benefits

Why it matters

Related questions