Padrão Repository: A Abstração que Transformou o Acesso a Dados em Aplicações .NET

No desenvolvimento de software moderno, uma das decisões mais críticas é como estruturar o acesso a dados. O padrão Repository emergiu como uma das soluções mais elegantes para este desafio, criando uma camada de abstração entre sua lógica de negócios e os mecanismos de armazenamento. Neste artigo, vamos explorar:

• O que é o padrão Repository e por que ele foi criado;
• Como ele se diferencia de outras abordagens;
• Seu relacionamento com outros padrões como Unit of Work;
• Quando usar (e quando não usar) esta abordagem;

---

Nos primórdios do desenvolvimento de aplicações, o acesso a dados era frequentemente implementado de forma direta e desestruturada. Os desenvolvedores escreviam queries SQL diretamente nos controllers, resultando em:

• Alto acoplamento: A lógica de negócios ficava intimamente ligada ao esquema do banco de dados;
• Dificuldade de teste: Era complexo isolar componentes para testes unitários;
• Falta de padronização: Diferentes partes do sistema acessavam dados de formas distintas;
• Complexidade na manutenção: Mudanças no esquema do banco exigiam alterações em múltiplos pontos do código;

// Exemplo do problema: acesso direto a dados no controller
public class ProdutoController : Controller
{
    public IActionResult Listar()
    {
        using (var connection = new SqlConnection(connectionString))
        {
            var produtos = connection.Query<Product>("SELECT * FROM Products");
            return View(produtos);
        }
    }
}

O padrão Repository foi formalizado como parte do Domain-Driven Design (DDD) por Eric Evans em seu livro seminal de 2004. A ideia central era:

"Fornecer uma abstração de coleção em memória para objetos de domínio, escondendo os detalhes de como e onde esses objetos são persistidos."

Esta abordagem trouxe vários benefícios:

1. Separação de preocupações: A lógica de negócios não precisa saber como os dados são armazenados;
2. Testabilidade: Podemos facilmente mockar o Repository para testes unitários;
3. Flexibilidade: A fonte de dados pode ser trocada sem afetar o domínio;
4. Consistência: Todas as operações de dados seguem o mesmo padrão;

---

O padrão Repository ocupa um espaço único no ecossistema de acesso a dados, diferenciando-se significativamente de outras abordagens comuns. Para entender seu valor, vamos contrastá-lo com três alternativas principais:

Repository vs Acesso Direto ao Banco
Antes da popularização dos ORMs, era comum ver aplicações acessando bancos de dados diretamente:

// Abordagem tradicional sem Repository
public List<Cliente> GetClientesPremium()
{
    using (var connection = new SqlConnection(connectionString))
    {
        return connection.Query<Cliente>(
            "SELECT * FROM Clientes WHERE Premium = 1").ToList();
    }
}

Problemas:

• SQL hardcoded em toda a aplicação;
• Difícil manutenção quando o esquema muda;
• Quase impossível de testar unitariamente;

O Repository resolve isso encapsulando todas as operações de dados em uma única camada.

Repository vs ORM Direto (Entity Framework Core)

Muitos desenvolvedores questionam: "Por que usar Repository se o EF Core já é uma abstração?"

// Uso direto do DbContext (sem Repository)
public class ProdutoService
{
    private readonly AppDbContext _context;

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

    public List<Produto> GetProdutosEmEstoque()
    {
        return _context.Produtos.Where(p => p.Estoque > 0).ToList();
    }
}

Diferenças chave:

1. Nível de abstração: Repository esconde completamente o ORM usado;
2. Flexibilidade: Facilita trocar EF por Dapper ou outro ORM;
3. Contrato explícito: Interface do Repository define claramente as operações disponíveis;

Repository vs Micro ORMs (Dapper)

Enquanto Dapper é excelente para performance, ele não oferece:

• Abstração de operações CRUD;
• Gerenciamento de estado;
• Fácil substituição por outra tecnologia;

O Repository adiciona essa camada organizacional.

---

O Repository raramente trabalha sozinho. Ele faz parte de um ecossistema de padrões:

Repository + Unit of Work
A combinação mais clássica e poderosa:

Vantagens:

• Controle transacional centralizado;
• Coordenação entre múltiplos repositories;
• Padronização de operações de persistência;

Repository + Specification Pattern
Para queries complexas:

public interface ISpecification<T>
{
    Expression<Func<T, bool>> Criteria { get; }
    List<Expression<Func<T, object>>> Includes { get; }
}

public class ProdutosEmEstoqueSpec : ISpecification<Produto>
{
    public Expression<Func<Produto, bool>> Criteria => p => p.Estoque > 0;
    public List<Expression<Func<Produto, object>>> Includes => new() { p => p.Categoria };
}

Repository + CQRS

Em arquiteturas mais avançadas:
[Command Side] → [Repository] → [Banco de Dados]
[Query Side] → [Queries Diretas] → [Cache/Read Model]

---

Casos Ideais para Repository

Para ajudar a decidir quando o padrão Repository é a escolha certa, veja este fluxograma de decisão:

---

O padrão Repository, quando aplicado corretamente, oferece:

✔ Separação clara de responsabilidades;
✔ Flexibilidade tecnológica;
✔ Testabilidade aprimorada;
✔ Manutenibilidade a longo prazo;

Porém, como qualquer padrão, não é uma solução universal. A chave está em:

1. Avaliar as necessidades reais do projeto;
2. Implementar de forma moderada;
3. Manter o foco no domínio;

Em projetos .NET modernos, uma abordagem equilibrada pode ser:

• Usar Repository para operações de escrita/comando;
• Usar abordagens mais diretas (Dapper, queries) para leitura;

Referências Úteis
📌 Repository Pattern (Microsoft Docs)

📌 Repository Pattern (Martin Fowler)

E você? Como tem utilizado o padrão Repository em seus projetos? Compartilhe suas experiências nos comentários!