O que é o padrão Repository?

Question

Accepted Answer

O padrão **Repository** abstrai **acesso a dados** por trás de uma interface semelhante a uma coleção — separando a lógica de negócio de como os dados são armazenados e recuperados. Ele desacopla a aplicação das fontes de dados (bancos de dados, APIs), melhorando a testabilidade e manutenibilidade.

## O que o padrão Repository faz

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

## Exemplo

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

## Benefícios

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

## Por que isso importa

Compreender o padrão Repository é valioso porque é um **padrão comum e prático** para separar limpa e claramente a lógica de negócio do acesso a dados, sendo assim conhecimento de design relevante.

O padrão Repository abstrai o acesso a dados por trás de uma interface semelhante a uma coleção (findById, save, delete), **ocultando como e onde os dados são armazenados** para que a lógica de negócio use o repositório em vez do banco de dados diretamente.

Compreender o que ele faz (fornecendo uma interface limpa de acesso a dados que oculta o armazenamento real, separando o *quê* das operações de dados do *como* elas são implementadas) é o conhecimento central.

Compreender os **benefícios** é fundamental: **desacoplamento** (a lógica de negócio não depende de detalhes de acesso a dados como o banco de dados específico, ORM ou API, permitindo trocar fontes de dados sem alterar a lógica de negócio — um benefício arquitetural valioso), **testabilidade** (usar repositórios mock/fake em testes para que nenhum banco de dados real seja necessário — importante para testes unitários da lógica de negócio), **acesso a dados centralizado** (lógica de consulta em um único lugar para manutenibilidade e consistência), e **arquitetura mais limpa** (separação clara entre lógica de domínio/negócio e dados).

Esses benefícios tornam o padrão Repository praticamente valioso para aplicações mantíveis e testáveis.

Compreender que é comum em **arquiteturas em camadas/limpas** e funciona com injeção de dependência clarifica seu lugar na arquitetura moderna.

O padrão Repository é amplamente usado porque separar a lógica de negócio do acesso a dados (para testabilidade, manutenibilidade e flexibilidade) é uma necessidade comum e importante.

Como o padrão Repository é um padrão comum e prático para separar limpa e claramente a lógica de negócio do acesso a dados (desacoplamento, testabilidade, acesso a dados centralizado, arquitetura mais limpa) — uma necessidade comum e importante — e é central para arquiteturas em camadas/limpas, e já que compreender o que ele faz e seus benefícios é relevante para construir aplicações mantíveis, compreender o padrão Repository é conhecimento de design valioso e praticamente relevante — um padrão frequentemente usado para separar lógica de negócio do acesso a dados, fornecendo desacoplamento e testabilidade, central para arquiteturas limpas/em camadas, e conhecimento de design importante para construir aplicações mantíveis e testáveis com separação clara entre lógica e dados.