Sobre o Repository Pattern

Visão geral

O Repository Pattern é um padrão de projeto cujo objetivo é abstrair o acesso a dados, criando uma separação clara entre o domínio da aplicação e os mecanismos de persistência.

Ele define contratos que representam coleções de objetos do domínio, permitindo que a aplicação leia e grave dados sem conhecer detalhes de infraestrutura.

O padrão não depende de banco de dados, ORM ou tecnologia específica. Pode ser aplicado a qualquer forma de acesso a dados externos, como:

• bancos relacionais ou não relacionais

• arquivos

• APIs

• serviços externos

• filas

• caches

O valor do padrão está no isolamento: o domínio expressa regras e intenções; a infraestrutura cuida dos detalhes técnicos.

---

Origem e motivação

O Repository Pattern surgiu para resolver um problema clássico: código de negócio acoplado diretamente à persistência, como:

• SQL explícito

• estrutura física de banco

• APIs específicas de acesso a dados

Esse acoplamento tornava o sistema difícil de evoluir, testar e manter. Qualquer mudança na persistência se espalhava pela aplicação.

A premissa é simples e continua atual:

O domínio deve depender de abstrações, não de infraestrutura.

ORMs facilitaram acesso a dados, mas não resolvem o problema arquitetural.

---

O que é um Repository

Um repositório representa uma coleção orientada ao domínio. Ele:

• expõe operações de leitura e gravação

• trabalha com entidades e agregados

• oculta completamente a origem dos dados

O domínio não sabe:

• de onde os dados vêm

• se existe SQL

• se há ORM

• se existe cache

• se há serviços externos

Ele conhece apenas o contrato.

---

O que o Repository Pattern não é

É essencial separar conceito de implementação:

• não é ORM

• não é Entity Framework

• não é DbSet

• não é CRUD automático

• não é obrigação arquitetural

O Repository Pattern é uma ferramenta arquitetural, não um dogma.

---

Repository Pattern e domínio

No modelo clássico, as interfaces de repositório pertencem ao domínio ou à camada de aplicação, nunca à infraestrutura.

Isso garante que:

• o domínio não dependa de tecnologia

• a persistência possa ser trocada

• o código de negócio seja testável isoladamente

O princípio é simples: o domínio define o que precisa, não como será feito.

---

Implementações concretas

As implementações dos repositórios vivem na infraestrutura. É ali que entram:

• bancos de dados

• ORMs

• providers específicos

• mecanismos externos de persistência

Uma implementação pode usar:

• Entity Framework + SQL Server

• Dapper

• acesso direto a arquivos

• chamadas HTTP

Para o domínio, isso é irrelevante.

---

Repository Pattern e ORMs

ORMs resolvem problemas técnicos:

• mapeamento

• queries

• transações

Repositories resolvem problemas arquiteturais:

• dependência

• acoplamento

• clareza de intenção

Um ORM pode existir dentro do repositório. O contrato do domínio nunca deve ser definido pelo ORM.

Se abstrações de persistência vazam para o domínio, o padrão foi quebrado.

---

Repositório genérico vs repositório específico

O uso de repositórios genéricos (IRepository<T>) é uma armadilha comum.

Na prática, eles tendem a:

• esconder a intenção do domínio

• incentivar CRUD sem significado

• virar apenas um proxy do ORM

Repositórios orientados a agregados e casos reais do domínio produzem sistemas mais claros, previsíveis e sustentáveis.

---

Relação com Unit of Work

Muitos ORMs já implementam Unit of Work implicitamente.

Duplicar esse conceito costuma gerar:

• sobreposição

• complexidade desnecessária

A separação conceitual é clara:

• Repository → acesso aos dados

• Unit of Work → consistência transacional

Nem sempre ambos precisam ser explícitos.

---

Benefícios

Quando bem aplicado, o Repository Pattern oferece:

• isolamento entre domínio e infraestrutura

• facilidade de testes

• menor acoplamento tecnológico

• maior clareza de intenção

• melhor evolução do sistema ao longo do tempo

---

Limitações e cuidados

O padrão não é universal. Em sistemas simples, pode:

• adicionar camadas desnecessárias

• aumentar o volume de código

• dificultar a navegação

Repositórios mal desenhados podem:

• virar serviços gordos

• duplicar regras de negócio

• mascarar problemas de modelagem

Ele resolve um problema específico: dependência da persistência.

---

Quando usar

Use quando:

• existe domínio relevante

• há regras de negócio claras

• a persistência pode mudar

• testes isolados são importantes

---

Quando evitar

Evite quando:

• a aplicação é puramente CRUD

• não há domínio real

• a persistência é trivial

• a complexidade não se justifica

---

O erro clássico (e muito comum)

Expor ORM no contrato do domínio:

public interface IProductRepository
{
    DbSet<Product> Products { get; }
}

Isso não é Repository Pattern. É o Entity Framework vazando para o domínio.

Consequências:

• o DbSet vira o repositório

• o domínio passa a depender do EF

• trocar a persistência vira trauma

Esse é exatamente o problema que o padrão nasceu para resolver.

---

Forma clássica (e correta)

Interface no domínio

public interface IProductRepository
{
    Product GetById(Guid id);
    void Add(Product product);
}

Implementação na infraestrutura

public class ProductRepository : IProductRepository
{
    private readonly AppDbContext _context;

    public ProductRepository(AppDbContext context)
    {
        _context = context;
    }

    public Product GetById(Guid id)
        => _context.Products.Find(id);

    public void Add(Product product)
        => _context.Products.Add(product);
}

Aqui:

• EF é detalhe

• SQL Server é detalhe

• o domínio permanece intacto

---

Conclusão

O Repository Pattern é um padrão clássico, criado para resolver um problema real — e continua relevante quando aplicado com critério.

Ele não compete com ORMs modernos nem substitui boas decisões de design. Seu valor está na clareza de responsabilidades e na proteção do domínio contra detalhes transitórios de tecnologia.

Arquitetura sólida não segue moda. Ela respeita fundamentos.

Arquitetura sólida não segue moda. Ela respeita fundamentos — e o Repository Pattern é um deles, quando usado pelo motivo certo.