Kas yra Repository pattern?

Question

Accepted Answer

**Repository** pattern abstrahuoja **duomenų prieigą** už kolekcijai panašios sąsajos — atskirdamas verslo logiką nuo to, kaip duomenys saugomi ir gaunami. Jis atriša programą nuo duomenų šaltinių (duomenų bazės, API), pagerinant testuojamumą ir palaikomumą.

## Ką Repository pattern daro

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

## Pavyzdys

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

## Privalumai

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

## Kodėl tai svarbu

Supratimas apie Repository pattern yra vertingas, nes tai yra **dažnas, praktinis pattern**, skirtas gražiai atskirt verslo logiką nuo duomenų prieigos, todėl tai yra aktualus dizaino žinojimas.

Repository pattern abstrahuoja duomenų prieigą už kolekcijai panašios sąsajos (findById, save, delete), **paslėpdamas kaip ir kur duomenys saugomi**, kad verslo logika naudotų repository vietoje tiesioginio duomenų bazės.

Supratimas, ką jis daro (teikdamas švarią duomenų prieigos sąsają, kuri paslėpia faktinį saugojimą, atskiriant *ką* duomenų operacijos nuo *kaip* jos yra įgyvendintos) yra pagrindinė žinojimo dalis.

Supratimas apie **privalumus** yra esmingas: **atristumas** (verslo logika nepriklausoma nuo duomenų prieigos detalių, tokių kaip konkreti duomenų bazė, ORM arba API, todėl galite keisti duomenų šaltinius nekeisdami verslo logikos — vertingas architektūrinis privalumas), **testuojamumas** (mock/fake repositories naudojimas testuose, todėl tikra duomenų bazė nereikalinga — svarbu verslo logikos vienetiniam testavimui), **centralizuota duomenų prieiga** (užklausų logika vienoje vietoje palaikomumui ir nuoseklumui), ir **švaresnė architektūra** (aiški atskira duomenų ir verslo logikos sfera).

Šie privalumai daro Repository pattern praktiškai vertingą palaukomai, testuojamai programai.

Supratimas, kad jis yra dažnas **sluoksnuotoje/švarinė architektūroje** ir veikia su priklausomybės injekcija, paaiškina jo vietą šiuolaikinėje architektūroje.

Repository pattern yra plačiai naudojamas, nes verslo logikos atskyrimas nuo duomenų prieigos (dėl testuojamumo, palaikomumo ir lankstumo) yra dažnas, svarbus poreikis.

Kadangi Repository pattern yra dažnas, praktinis pattern, skirtas gražiai atskirt verslo logiką nuo duomenų prieigos (atristumas, testuojamumas, centralizuota duomenų prieiga, švaresnė architektūra) — dažnas, svarbus poreikis — ir yra centrinis sluoksnuotoje/švarinėje architektūrose, ir kadangi supratimas, ką jis daro ir jo privalumų, yra aktualus norint kurti palaukomai programas, supratimas apie Repository pattern yra vertingas, praktiškai aktualus dizaino žinojimas — dažnai naudojamas pattern verslo logikos atskyrimo nuo duomenų prieigos tikslams, teikiantis atristumą ir testuojamumą, centralinis švarinėje/sluoksnuotoje architektūrose, ir svarbus dizaino žinojimas, reikalingas kurti palaukomai, testuojamas programas su švaria atskira logikos ir duomenų sfera.