Implementando Repository Pattern com C#, Entity Framework e .NET

O que é o repository pattern

O repository pattern encapsula a lógica de acesso a dados e cria uma abstração entre a aplicação e o banco. Em outras palavras, o restante do código pede dados ao repositório sem saber como eles são lidos ou gravados.

Dessa forma, a lógica de persistência fica separada do domínio da aplicação. Por isso, o código se torna mais organizado, testável e fácil de evoluir.

O padrão é especialmente útil em aplicações com Entity Framework Core. Afinal, ele permite controlar leitura e escrita sem expor a infraestrutura do banco de dados para serviços e endpoints.

Vale lembrar que o próprio DbContext já combina os padrões Unit of Work e Repository, como explica a documentação da Microsoft. Mesmo assim, um repositório próprio continua útil quando você quer um contrato explícito, focado nas operações que o domínio realmente precisa.

Criando os models

Antes de aplicar o repository pattern, você precisa definir os modelos que representam as entidades no banco. Os models são classes que correspondem às tabelas e que o EF Core usa para mapear os dados.

Com eles, você trabalha com objetos em C# em vez de escrever SQL diretamente. Assim, a manutenção e a reutilização do código ficam mais simples.

public class User
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
}

Instalando o Entity Framework Core

O Entity Framework Core é o ORM (Object-Relational Mapper) da Microsoft para .NET. Ele permite interagir com o banco de dados usando classes C#, sem SQL escrito à mão na maior parte dos casos.

Antes de definir o contexto e o repository pattern, instale os pacotes necessários. Para isso, execute os comandos abaixo no terminal, dentro da pasta do projeto:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

O primeiro pacote traz o provedor do SQL Server. Já o segundo adiciona as ferramentas de linha de comando, como as migrations.

Se você usa outro banco, como PostgreSQL ou MySQL, troque Microsoft.EntityFrameworkCore.SqlServer pelo provedor correspondente. Todo o restante do código continua igual.

Este tutorial usa o SQL Server. Caso precise de ajuda para subir o banco localmente, consulte o guia de SQL Server no Docker.

Criando o contexto do Entity Framework

O DbContext é a peça central do Entity Framework Core e funciona como uma ponte entre a aplicação e o banco de dados. Ele gerencia as operações de leitura e gravação e também oferece um ambiente transacional para manipular os dados.

Segundo a documentação oficial, cada instância de DbContext representa uma sessão com o banco. Além disso, ela foi pensada para uma única unidade de trabalho, ou seja, tem vida curta.

public class AppDbContext : DbContext
{
    public DbSet<User> Users { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Define explicitamente a chave primária
        modelBuilder.Entity<User>().HasKey(u => u.Id);
    }
}

Criando o repositório de usuário

Agora você vai aplicar o repository pattern na entidade User. O repositório será a camada intermediária entre a aplicação e o banco, encapsulando toda a lógica de acesso e persistência.

Com o repository pattern, as operações de usuários ficam centralizadas em um único lugar. Portanto, a lógica de dados não se espalha pelo código.

public interface IUserRepository
{
    Task<User?> GetByIdAsync(int id);
    Task<User?> GetByEmailAsync(string email);
    Task<IEnumerable<User>> GetAllAsync();
    Task AddAsync(User user);
    Task UpdateAsync(User user);
    Task DeleteAsync(int id);
}

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

public async Task<User?> GetByIdAsync(int id)
{
    return await _context.Users.FindAsync(id);
}

public async Task<User?> GetByEmailAsync(string email)
{
    return await _context.Users.FirstOrDefaultAsync(u => u.Email == email);
}

public async Task<IEnumerable<User>> GetAllAsync()
{
    return await _context.Users.ToListAsync();
}

public async Task AddAsync(User user)
{
    await _context.Users.AddAsync(user);
    await _context.SaveChangesAsync();
}

public async Task UpdateAsync(User user)
{
    _context.Users.Update(user);
    await _context.SaveChangesAsync();
}

public async Task DeleteAsync(int id)
{
    var user = await GetByIdAsync(id);
    if (user != null)
    {
        _context.Users.Remove(user);
        await _context.SaveChangesAsync();
    }
}

public class UserRepository : IUserRepository
{
    private readonly AppDbContext _context;

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

    public async Task<User?> GetByIdAsync(int id)
    {
        return await _context.Users.FindAsync(id);
    }

    public async Task<User?> GetByEmailAsync(string email)
    {
        return await _context.Users.FirstOrDefaultAsync(u => u.Email == email);
    }

    public async Task<IEnumerable<User>> GetAllAsync()
    {
        return await _context.Users.ToListAsync();
    }

    public async Task AddAsync(User user)
    {
        await _context.Users.AddAsync(user);
        await _context.SaveChangesAsync();
    }

    public async Task UpdateAsync(User user)
    {
        _context.Users.Update(user);
        await _context.SaveChangesAsync();
    }

    public async Task DeleteAsync(int id)
    {
        var user = await GetByIdAsync(id);
        if (user != null)
        {
            _context.Users.Remove(user);
            await _context.SaveChangesAsync();
        }
    }
}

Configurando o DbContext

Antes de registrar o DbContext, a aplicação precisa ler a string de conexão do arquivo appsettings.json. Dessa forma, dados sensíveis não ficam fixos no código-fonte.

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost,1433;Database=YOUR_DATABASE;User ID=sa;Password=1q2w3e4r@#$;Trusted_Connection=False;TrustServerCertificate=True;"
  }
}

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

Registrando o repository pattern na injeção de dependência

A injeção de dependência (Dependency Injection, ou DI) é um padrão que gerencia a criação e a entrega de dependências dentro da aplicação. No .NET, ela fornece instâncias de classes para outras classes sem que você precise criá-las manualmente.

Ao registrar o repositório no container, ele passa a ser injetado automaticamente em serviços, endpoints e controllers. Isso traz três benefícios:

• Gerenciamento do ciclo de vida: o container garante que as instâncias corretas sejam usadas.
• Facilidade para testes: você substitui a implementação por um mock com facilidade.
• Código desacoplado: as classes não criam suas dependências por conta própria.

Para registrar o repositório, adicione a linha abaixo no Program.cs:

builder.Services.AddScoped<IUserRepository, UserRepository>();

No repository pattern, o tempo de vida scoped não é por acaso. Segundo o guia de arquitetura da Microsoft, repositório e DbContext devem compartilhar o mesmo escopo, porque um repositório singleton com um contexto scoped causa sérios problemas de concorrência.

Se quiser revisar os tempos de vida disponíveis, o artigo sobre injeção de dependência no ASP.NET Core detalha cada um deles.

Usando o repository pattern com Minimal APIs

Com o repository pattern registrado, você pode usar o repositório diretamente em Minimal APIs. Nesse modelo, os endpoints recebem as dependências como parâmetros, sem controllers:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddScoped<IUserRepository, UserRepository>();

var app = builder.Build();

app.MapGet("/users", async (IUserRepository repository) =>
{
    return Results.Ok(await repository.GetAllAsync());
});

app.MapGet("/users/{id}", async (int id, IUserRepository repository) =>
{
    var user = await repository.GetByIdAsync(id);
    return user != null ? Results.Ok(user) : Results.NotFound();
});

app.MapPost("/users", async (User user, IUserRepository repository) =>
{
    await repository.AddAsync(user);
    return Results.Created($"/users/{user.Id}", user);
});

app.Run();

Cada endpoint declara IUserRepository como parâmetro, e o ASP.NET Core resolve a instância pelo container. Assim, nenhum endpoint conhece o AppDbContext diretamente.

As Minimal APIs oferecem uma forma mais concisa de expor endpoints HTTP. Para conhecer melhor esse modelo, veja o artigo sobre Minimal APIs no ASP.NET.

Usando o repository pattern no controller

O repository pattern também funciona em uma API baseada em controllers. Nesse caso, a dependência chega pelo construtor:

[ApiController]
[Route("api/[controller]")]
public class UserController : ControllerBase
{
    private readonly IUserRepository _userRepository;

    public UserController(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }

    [HttpGet]
    public async Task<IActionResult> GetAll()
    {
        var users = await _userRepository.GetAllAsync();
        return Ok(users);
    }

    [HttpGet("{id}")]
    public async Task<IActionResult> GetById(int id)
    {
        var user = await _userRepository.GetByIdAsync(id);
        if (user == null) return NotFound();
        return Ok(user);
    }

    [HttpPost]
    public async Task<IActionResult> Create(User user)
    {
        await _userRepository.AddAsync(user);
        return CreatedAtAction(nameof(GetById), new { id = user.Id }, user);
    }
}

Lembre-se de registrar os controllers com builder.Services.AddControllers() e mapeá-los com app.MapControllers(). Depois disso, o controller passa a responder em /api/user.

Note que o controller não tem nenhuma referência ao Entity Framework Core. Portanto, trocar a tecnologia de persistência exigiria apenas uma nova implementação de IUserRepository.

Testando código que usa o repository pattern

Uma das maiores vantagens do repository pattern aparece nos testes. Como serviços e endpoints dependem apenas da interface, você substitui o repositório real por uma implementação falsa.

Por exemplo, uma implementação em memória pode guardar usuários em uma lista. Dessa forma, o teste valida a regra de negócio sem abrir conexão com o SQL Server.

Bibliotecas como Moq ou NSubstitute geram esses dublês automaticamente a partir de IUserRepository. Se quiser revisar os conceitos, o artigo sobre fundamentos dos testes de unidade é um bom ponto de partida.

Contudo, os testes do próprio UserRepository devem usar um banco real ou um container. Afinal, o comportamento das consultas depende do provedor configurado.

Cuidados ao aplicar o repository pattern

O guia de arquitetura de microsserviços da Microsoft lembra que o DbContext já é, por si só, uma combinação de Unit of Work e Repository. Por isso, em aplicações muito simples, usar o contexto diretamente produz menos código.

Outro cuidado envolve o SaveChangesAsync dentro de cada método. Quando uma operação precisa alterar várias entidades de forma atômica, vale centralizar o salvamento em uma unidade de trabalho, em vez de salvar a cada chamada.

Também evite expor IQueryable na interface do repository pattern. Caso contrário, detalhes do EF Core vazam para as camadas superiores e o desacoplamento se perde.

Para se aprofundar, consulte o capítulo sobre a camada de persistência com Entity Framework Core na documentação oficial.

Conclusão

O repository pattern ajuda a organizar a lógica de acesso a dados, separar responsabilidades e facilitar os testes. Com C# e Entity Framework Core, você cria repositórios reutilizáveis e robustos para manipular dados com eficiência.

Neste artigo, você criou o model, o DbContext, a interface e a implementação do repositório. Em seguida, registrou tudo na injeção de dependência e consumiu o repositório em Minimal APIs e em controllers.

Com essa implementação, você tem uma base flexível e de fácil manutenção para trabalhar com banco de dados em aplicações .NET. Agora, basta aplicar o repository pattern às demais entidades do seu projeto.

FAQ

O repository pattern é obrigatório com Entity Framework Core?

Não, porque o DbContext já combina os padrões Repository e Unit of Work. Um repositório próprio vale a pena quando você quer um contrato explícito e testes mais simples.

Qual tempo de vida usar para o repositório na DI?

Use scoped, o mesmo tempo de vida padrão do DbContext. Um repositório singleton com contexto scoped causa problemas de concorrência.

Posso usar o repository pattern com PostgreSQL?

Sim, basta trocar o provedor do EF Core e o método UseSqlServer por UseNpgsql. A interface e os consumidores continuam iguais.

Devo criar um repositório genérico?

Um repositório genérico reduz repetição em CRUDs simples. No entanto, repositórios específicos expressam melhor as operações de cada entidade.

Por que usar métodos assíncronos no repositório?

Os métodos assíncronos liberam a thread enquanto o banco responde. Assim, a API atende mais requisições com os mesmos recursos.