Repository Pattern no .NET: Um Guia Direto ao Ponto

Vamos cortar o papo furado e falar sobre o Repository Pattern como gente de verdade. Pense nele como um intermediário entre sua lógica de negócio e seu banco de dados — um que realmente facilita sua vida.

Por Que Você Deveria se Importar?

Imagina a situação: Você está construindo uma aplicação e o código de banco de dados está em todo lugar. Amanhã, seu chefe diz "Vamos trocar o SQL Server por MongoDB." Você provavelmente ia querer chorar, né? É aí que o Repository Pattern te salva.

Em bom português: É uma camada que fica entre sua aplicação e seu banco de dados, para que você possa trocar a fonte de dados sem reescrever metade do seu código.

O Exemplo do Mundo Real

Digamos que você está construindo um blog simples. Você precisa salvar e buscar posts. Veja como a maioria das pessoas começa:

// ❌ A abordagem "vou me arrepender depois"
public class BlogService
{
    private readonly DbContext _db;

    public BlogPost GetPost(int id)
    {
        return _db.BlogPosts.FirstOrDefault(p => p.Id == id);
    }
}

Isso funciona, mas agora seu BlogService está casado com o Entity Framework. Boa sorte testando isso ou trocando de banco.

Entra o Repository Pattern

Aqui está o jeito mais esperto:

Passo 1: Defina o Que Você Precisa (A Interface)

public interface IBlogRepository
{
    BlogPost GetById(int id);
    IEnumerable<BlogPost> GetAll();
    void Add(BlogPost post);
    void Update(BlogPost post);
    void Delete(int id);
}

Este é o seu contrato. Percebeu como ele não diz nada sobre banco de dados? Isso é proposital.

Passo 2: Implemente (O Repositório de Verdade)

public class BlogRepository : IBlogRepository
{
    private readonly ApplicationDbContext _context;

    public BlogRepository(ApplicationDbContext context)
    {
        _context = context;
    }

    public BlogPost GetById(int id)
    {
        return _context.BlogPosts.FirstOrDefault(p => p.Id == id);
    }

    public IEnumerable<BlogPost> GetAll()
    {
        return _context.BlogPosts.ToList();
    }

    public void Add(BlogPost post)
    {
        _context.BlogPosts.Add(post);
        _context.SaveChanges();
    }

    public void Update(BlogPost post)
    {
        _context.BlogPosts.Update(post);
        _context.SaveChanges();
    }

    public void Delete(int id)
    {
        var post = GetById(id);
        if (post != null)
        {
            _context.BlogPosts.Remove(post);
            _context.SaveChanges();
        }
    }
}

Passo 3: Use no Seu Service

public class BlogService
{
    private readonly IBlogRepository _repository;

    public BlogService(IBlogRepository repository)
    {
        _repository = repository;
    }

    public BlogPost GetPost(int id)
    {
        return _repository.GetById(id);
    }

    public void PublishPost(BlogPost post)
    {
        post.PublishedAt = DateTime.Now;
        _repository.Add(post);
    }
}

Passo 4: Configure (Injeção de Dependência)

No seu Program.cs:

builder.Services.AddScoped<IBlogRepository, BlogRepository>();
builder.Services.AddScoped<BlogService>();

O Que Acabou de Acontecer?

Seu BlogService agora não tem a menor ideia sobre Entity Framework ou banco de dados. Ele só sabe que pode pedir posts e salvá-los.

Quer trocar para Dapper? MongoDB? Um arquivo JSON? Basta criar uma nova implementação de IBlogRepository. O código do seu service fica intocado.

Os Benefícios Reais

1. Testes ficam moleza - Faça mock do IBlogRepository e teste sua lógica de negócio sem tocar no banco
2. Flexibilidade - Troque a fonte de dados sem reescrever toda sua aplicação
3. Código mais limpo - Cada classe tem uma responsabilidade e faz bem feito
4. Sanidade da equipe - Seus colegas não vão te odiar quando tiverem que dar manutenção nisso depois

Quando NÃO Usar

Papo reto: Se você está construindo uma aplicação CRUD pequena com 3 tabelas, isso pode ser exagero. Não faça over-engineering. Mas se sua aplicação está crescendo ou você sabe que vai crescer, o Repository Pattern é seu amigo.

Resumindo

O Repository Pattern não é mágica — é apenas boa organização. Você está traçando uma linha clara entre "como armazenamos dados" e "o que fazemos com dados."

O você do futuro (e seus colegas) vão agradecer o você do presente por essa escolha.

Dúvidas ou histórias de guerra usando o Repository Pattern? Adoraria ouvir. Me manda uma mensagem!

Este artigo foi revisado e aprimorado com o uso de IA.