Co to jest wzorzec Repository?

Question

Accepted Answer

Wzorzec **Repository** abstrahuje **dostęp do danych** za interfejsem podobnym do kolekcji — oddzielając logikę biznesową od sposobu przechowywania i pobierania danych. Oddziela aplikację od źródeł danych (bazy danych, API), poprawiając testowalność i konserwacje.

## Co robi wzorzec Repository

```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
```

## Przykład

```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
```

## Zalety

```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
```

## Dlaczego to ważne

Rozumienie wzorca Repository jest cennym, ponieważ to **powszechny, praktyczny wzorzec** do czystego oddzielenia logiki biznesowej od dostępu do danych, dlatego jest to istotna wiedza projektowa.

Wzorzec Repository abstrahuje dostęp do danych za interfejsem podobnym do kolekcji (findById, save, delete), **ukrywając jak i gdzie dane są przechowywane**, tak aby logika biznesowa używała repozytorium zamiast bazy danych bezpośrednio.

Rozumienie tego, co robi (zapewnianie czystego interfejsu dostępu do danych, który ukrywa faktyczne przechowywanie, oddzielając *co* od operacji na danych od *jak* są one zaimplementowane) to podstawowa wiedza.

Rozumienie **zalet** jest kluczowe: **rozdzielenie** (logika biznesowa nie zależy od szczegółów dostępu do danych takich jak konkretna baza danych, ORM lub API, więc możesz zamienić źródła danych bez zmian w logice biznesowej — cenna korzyść architektoniczna), **testowalność** (używanie mock/fake repozytoriów w testach, aby nie była potrzebna rzeczywista baza danych — ważne dla testów jednostkowych logiki biznesowej), **scentralizowany dostęp do danych** (logika zapytań w jednym miejscu dla konserwacji i spójności) i **czystsza architektura** (jasne rozdzielenie między domeną/logiką biznesową i danymi).

Te zalety czynią wzorzec Repository praktycznie wartościowym dla konserwabilnych, testowalnych aplikacji.

Rozumienie, że jest powszechny w **architekturach warstwowych/czystych** i współpracuje z iniekcją zależności, wyjaśnia jego miejsce we współczesnej architekturze.

Wzorzec Repository jest szeroko stosowany, ponieważ oddzielenie logiki biznesowej od dostępu do danych (dla testowalności, konserwacji i elastyczności) to powszechna, ważna potrzeba.

Ponieważ wzorzec Repository to powszechny, praktyczny wzorzec do czystego oddzielenia logiki biznesowej od dostępu do danych (rozdzielenie, testowalność, scentralizowany dostęp do danych, czystsza architektura) — powszechna, ważna potrzeba — i jest centralny dla architektur czystych/warstwowych, oraz ponieważ rozumienie tego, co robi i jego zalet, jest istotne dla budowania konserwabilnych aplikacji, rozumienie wzorca Repository to cenna, praktycznie istotna wiedza projektowa — powszechnie stosowany wzorzec do oddzielenia logiki biznesowej od dostępu do danych, zapewniający rozdzielenie i testowalność, centralny dla czystych/warstwowych architektur i ważna wiedza projektowa do budowania konserwabilnych, testowalnych aplikacji z czystym rozdzieleniem między logiką a danymi.