EF Core vs Dapper: desempenho, produtividade e cenários de uso

Publicado em 25/10/2026 por Admin

Escolher a maneira correta de acessar o banco de dados é uma das decisões que influenciam a produtividade e o desempenho de uma aplicação .NET.

Entre as opções mais utilizadas estão o Entity Framework Core (EF Core) e o Dapper.

Embora as duas ferramentas permitam consultar e modificar dados em bancos relacionais, elas seguem propostas diferentes.

O EF Core é um ORM que oferece recursos para mapear entidades, construir consultas com LINQ, acompanhar alterações e gerenciar a persistência dos dados.

O Dapper é um micro-ORM que simplifica o uso do ADO.NET, permitindo executar comandos SQL e mapear os resultados para objetos .NET com pouca abstração.

Mas qual deles oferece melhor desempenho? Qual facilita mais a manutenção? E quando faz sentido utilizar cada um?

Neste artigo, vamos comparar EF Core e Dapper sob três perspectivas principais: desempenho, produtividade e cenários de uso.

1. O que é o Entity Framework Core?

O Entity Framework Core é um ORM, sigla para Object-Relational Mapper.

Sua função é permitir que a aplicação trabalhe com objetos .NET enquanto o framework cuida de parte do processo de tradução entre esses objetos e as estruturas relacionais do banco de dados.

Com EF Core, o desenvolvedor pode definir entidades, configurar relacionamentos, construir consultas com LINQ e persistir alterações utilizando um contexto de banco de dados.

Considere uma entidade simples:

public class Produto
{
    public int Id { get; set; }

    public string Nome { get; set; } = string.Empty;

    public decimal Preco { get; set; }
}

Um contexto pode expor essa entidade por meio de um DbSet:

using Microsoft.EntityFrameworkCore;

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions options)
        : base(options)
    {
    }

    public DbSet Produtos => Set();
}

Depois de configurar o contexto e a conexão, a aplicação pode consultar os produtos utilizando LINQ:

var produtos = await context.Produtos
    .Where(p => p.Preco > 100)
    .OrderBy(p => p.Nome)
    .ToListAsync();

O EF Core traduz a consulta para SQL compatível com o provedor de banco de dados utilizado.

Essa abordagem permite escrever consultas de maneira integrada à linguagem C#, reduzindo a necessidade de construir manualmente cada comando SQL.

Além das consultas, o EF Core oferece recursos para rastreamento de alterações, relacionamentos, transações, interceptadores e migrações de esquema.

2. O que é o Dapper?

O Dapper é um micro-ORM que adiciona métodos de consulta e execução a conexões ADO.NET.

Diferentemente do EF Core, ele não oferece o mesmo conjunto de recursos de mapeamento de entidades, rastreamento de alterações e gerenciamento de persistência.

O desenvolvedor escreve o SQL e utiliza o Dapper para executar o comando e mapear os resultados para objetos .NET.

Considerando a mesma entidade Produto, uma consulta pode ser escrita assim:

using Dapper;
using Microsoft.Data.SqlClient;

await using var connection = new SqlConnection(connectionString);

var sql = """
    SELECT Id, Nome, Preco
    FROM Produtos
    WHERE Preco > @PrecoMinimo
    ORDER BY Nome
    """;

var produtos = await connection.QueryAsync(
    sql,
    new { PrecoMinimo = 100m });

Nesse exemplo, o SQL é definido explicitamente.

O parâmetro PrecoMinimo é enviado separadamente, evitando a necessidade de concatenar o valor diretamente no comando.

Essa separação é importante para a segurança e a correção da consulta.

O Dapper executa o comando por meio da conexão ADO.NET e mapeia as colunas retornadas para as propriedades correspondentes da classe Produto.

O exemplo utiliza SQL Server por meio de Microsoft.Data.SqlClient. Para outros bancos, é necessário utilizar o provedor ADO.NET apropriado e ajustar o SQL quando houver diferenças de sintaxe.

3. EF Core vs Dapper: principais diferenças

A diferença central está no nível de abstração oferecido por cada ferramenta.

O EF Core procura facilitar o trabalho com entidades e operações de persistência. O Dapper procura simplificar a execução de SQL e o mapeamento dos resultados.

Característica	Entity Framework Core	Dapper
Tipo de ferramenta	ORM	Micro-ORM
Construção de consultas	LINQ, APIs do framework e SQL explícito	SQL explícito
Mapeamento de resultados	Integrado ao modelo de entidades	Mapeamento para objetos e resultados de consultas
Rastreamento de alterações	Disponível para entidades rastreadas	Não oferece o mesmo mecanismo de tracking do EF Core
Persistência de alterações	Pode ser realizada por meio de `SaveChanges`	O desenvolvedor executa comandos SQL
Relacionamentos	Configuração e carregamento de relacionamentos	Precisam ser tratados nas consultas e no mapeamento
Migrações de esquema	Ferramentas de migração disponíveis	Não oferece o mesmo sistema integrado de migrações
Controle do SQL	Pode gerar SQL a partir das consultas	O SQL é escrito explicitamente
Curva de aprendizado	Exige compreender o modelo e os comportamentos do ORM	Exige conhecimento de SQL e do mapeamento dos resultados
Casos de uso	Aplicações com operações de domínio e persistência integrada	Consultas SQL explícitas e cenários que se beneficiam de controle direto

Nenhuma dessas características torna uma ferramenta automaticamente superior à outra.

A escolha depende do tipo de consulta, do modelo de dados, da complexidade da aplicação e da experiência da equipe.

4. Qual oferece melhor desempenho?

Essa é provavelmente a pergunta mais comum quando se compara EF Core e Dapper.

Em muitos cenários, o Dapper pode apresentar menor overhead de execução e alocação por utilizar uma camada de abstração mais enxuta.

Entretanto, isso não significa que ele sempre será mais rápido em qualquer aplicação.

O desempenho depende de vários fatores:

Complexidade do SQL.
Quantidade de registros retornados.
Índices disponíveis.
Plano de execução do banco de dados.
Volume de dados transferidos.
Tempo de rede.
Estratégia de carregamento de relacionamentos.
Rastreamento de entidades.
Alocações de memória.
Quantidade de chamadas ao banco.

Uma consulta mal projetada pode ser lenta tanto no EF Core quanto no Dapper.

Da mesma forma, uma consulta eficiente, com bons índices e retorno limitado de dados, pode apresentar excelente desempenho em ambas as ferramentas.

A documentação oficial do EF Core destaca que aspectos como uso de índices, projeção de colunas, paginação e redução de viagens ao banco costumam ser fundamentais para otimizar consultas.

O overhead do EF Core

O EF Core realiza operações adicionais para oferecer recursos como tradução de LINQ, materialização de entidades e rastreamento de alterações.

Esses recursos têm um custo, mas também reduzem a quantidade de código que precisa ser escrito e mantido manualmente.

Em muitas aplicações, o overhead adicional não é o principal fator limitante.

Se o banco leva centenas de milissegundos para executar uma consulta, reduzir uma pequena parcela do processamento realizado pela aplicação pode ter impacto limitado no tempo total da requisição.

Nesses casos, melhorar o SQL, criar índices adequados ou reduzir o volume de dados pode produzir ganhos mais relevantes.

O overhead do Dapper

O Dapper possui uma camada mais enxuta para executar SQL e mapear os resultados.

Isso pode ser vantajoso em consultas frequentes, cenários de baixa latência ou aplicações que precisam controlar cuidadosamente o formato dos comandos executados.

Porém, a equipe passa a assumir mais responsabilidade pela construção das consultas e pelo gerenciamento de operações de persistência.

Se o SQL for ineficiente, o Dapper não corrigirá automaticamente o problema.

O uso de SQL explícito também exige atenção às alterações no esquema, aos parâmetros, aos relacionamentos e à manutenção das consultas.

Como comparar corretamente?

Uma comparação confiável exige testes realizados em condições equivalentes.

É necessário utilizar o mesmo banco de dados, o mesmo conjunto de dados, consultas funcionalmente equivalentes e configurações comparáveis.

Também vale medir mais do que o tempo médio de execução.

Observe a distribuição da latência, as alocações de memória, o consumo de CPU e o comportamento sob concorrência.

Benchmarks publicados podem ajudar a formular hipóteses, mas seus resultados não devem ser tratados como uma garantia de desempenho para qualquer aplicação.

5. Como otimizar consultas no EF Core?

Antes de substituir o EF Core por Dapper, vale verificar se a consulta atual pode ser otimizada.

Utilize projeções

Se a aplicação precisa apenas do nome e do preço dos produtos, não é necessário carregar todas as propriedades da entidade.

Uma projeção pode reduzir a quantidade de dados transferidos:

var produtos = await context.Produtos
    .Where(p => p.Preco > 100)
    .Select(p => new
    {
        p.Nome,
        p.Preco
    })
    .ToListAsync();

A projeção permite selecionar somente as colunas necessárias.

Isso pode reduzir o volume de dados retornados e evitar a materialização de entidades completas quando elas não são necessárias.

Utilize consultas sem rastreamento quando apropriado

Para consultas de leitura que não precisam acompanhar alterações nas entidades, AsNoTracking() pode reduzir o trabalho associado ao rastreamento.

var produtos = await context.Produtos
    .AsNoTracking()
    .Where(p => p.Preco > 100)
    .ToListAsync();

Essa abordagem é útil quando a aplicação precisa apenas consultar os dados.

Entretanto, se a intenção for modificar entidades carregadas e persistir as alterações por meio do contexto, o rastreamento pode ser necessário ou mais conveniente.

Evite carregar dados desnecessários

Carregar grandes quantidades de registros sem necessidade pode aumentar o tempo de resposta e o consumo de memória.

Utilize filtros, paginação e projeções adequadas.

Também tenha cuidado com relacionamentos que podem gerar muitas consultas ou multiplicar o número de linhas retornadas.

A escolha entre carregamento antecipado, explícito e outras estratégias deve considerar o formato dos dados e o SQL efetivamente gerado.

Analise o SQL gerado

O EF Core permite inspecionar o SQL produzido pelas consultas.

Isso ajuda a identificar filtros inadequados, carregamentos excessivos e possíveis problemas de desempenho.

Também é importante examinar o plano de execução no próprio banco de dados.

A presença de um ORM não elimina a necessidade de compreender SQL, índices e comportamento do mecanismo relacional.

6. Como otimizar consultas no Dapper?

O Dapper oferece controle explícito sobre o SQL, mas esse controle precisa ser utilizado corretamente.

Selecione apenas as colunas necessárias

Evite utilizar SELECT * quando a aplicação precisa apenas de algumas propriedades.

Por exemplo:

SELECT Id, Nome, Preco
FROM Produtos
WHERE Preco > @PrecoMinimo;

Essa consulta deixa claro quais dados serão retornados.

Em tabelas grandes, selecionar somente as colunas necessárias pode reduzir o volume de dados transferidos e processados.

Utilize parâmetros

Não concatene valores fornecidos pelo usuário diretamente no SQL.

Utilize parâmetros para separar os valores do texto do comando:

var produtos = await connection.QueryAsync(
    """
    SELECT Id, Nome, Preco
    FROM Produtos
    WHERE Nome = @Nome
    """,
    new { Nome = nomePesquisado });

O uso de parâmetros ajuda a prevenir SQL injection e permite que o provedor trate os valores de maneira apropriada.

Entretanto, parâmetros não substituem a validação dos dados nem tornam automaticamente seguro qualquer SQL construído dinamicamente.

Quando for necessário montar consultas dinâmicas, nomes de colunas, tabelas e direções de ordenação devem ser tratados com cuidado, pois esses elementos geralmente não podem ser fornecidos como parâmetros comuns.

Considere o tamanho dos resultados

Por padrão, as consultas comuns do Dapper utilizam comportamento de buffering, carregando os resultados antes de retorná-los ao chamador.

Para conjuntos muito grandes, pode ser interessante avaliar estratégias de leitura não armazenada integralmente em memória, utilizando os recursos apropriados da biblioteca.

Essa mudança deve ser testada com atenção, porque altera o ciclo de vida da leitura dos dados e pode afetar o uso da conexão.

Não ignore os índices

O Dapper não substitui a análise do banco de dados.

Se a consulta realiza uma varredura desnecessária em uma tabela grande, a simples utilização do micro-ORM não resolverá o problema.

O SQL, os índices e o plano de execução continuam sendo fatores decisivos.

7. Qual ferramenta oferece maior produtividade?

Desempenho não é o único critério relevante.

A produtividade envolve a velocidade com que a equipe desenvolve funcionalidades, corrige problemas e mantém o sistema ao longo do tempo.

Produtividade com EF Core

O EF Core pode reduzir bastante o código necessário para operações comuns de persistência.

Considere uma aplicação que possui clientes, pedidos, produtos e itens de pedido.

Com um modelo de entidades bem configurado, o framework oferece recursos para representar relacionamentos, consultar dados e persistir alterações.

O sistema também pode utilizar migrações para versionar alterações no esquema do banco.

Isso não elimina a necessidade de compreender o SQL gerado, mas oferece uma estrutura integrada para organizar o acesso aos dados.

Para aplicações com regras de negócio e entidades relacionadas, essa abordagem pode facilitar a manutenção.

Produtividade com Dapper

O Dapper pode ser mais produtivo quando a equipe já conhece bem SQL e precisa executar consultas específicas.

Em vez de configurar um modelo completo de entidades para cada operação, o desenvolvedor pode escrever o comando SQL diretamente e mapear os resultados para um DTO.

Isso é especialmente útil em consultas de relatórios, painéis, exportações e endpoints que retornam formatos de dados específicos.

Por outro lado, o SQL precisa ser mantido explicitamente.

À medida que o número de consultas cresce, torna-se importante organizar o acesso aos dados, centralizar responsabilidades e criar testes que ajudem a detectar incompatibilidades com o esquema.

O Dapper reduz algumas abstrações, mas não elimina a necessidade de uma boa arquitetura.

8. Quando escolher EF Core?

O EF Core costuma ser uma boa opção quando:

A aplicação possui um modelo de domínio com entidades e relacionamentos.
Existem muitas operações de inclusão, atualização e exclusão.
A equipe deseja utilizar LINQ para construir consultas.
O rastreamento de alterações simplifica a persistência.
As migrações do banco fazem parte do fluxo de desenvolvimento.
O projeto exige uma camada de persistência integrada ao restante da aplicação.
A produtividade e a consistência do código são prioridades.

Imagine um sistema de gestão comercial com clientes, pedidos, produtos, pagamentos e histórico de operações.

Esse tipo de aplicação pode se beneficiar dos recursos de mapeamento, relacionamentos e persistência oferecidos pelo EF Core.

Isso não significa que todas as consultas devam utilizar LINQ. O framework também permite executar SQL explícito em cenários nos quais isso seja necessário.

9. Quando escolher Dapper?

O Dapper pode ser uma boa opção quando:

A equipe precisa controlar diretamente o SQL.
Existem consultas complexas que já foram cuidadosamente otimizadas.
O sistema possui relatórios com projeções específicas.
A aplicação executa operações orientadas a consultas.
O projeto utiliza uma abordagem explícita para acesso aos dados.
A equipe possui experiência com SQL e quer uma camada leve de mapeamento.
O custo adicional de um ORM mais abrangente não oferece benefícios suficientes para determinada operação.

Considere uma API de relatórios que executa consultas com agregações, junções e filtros específicos.

O Dapper permite escrever o SQL diretamente e mapear o resultado para um objeto de resposta.

Esse modelo pode oferecer controle e simplicidade para aquela consulta.

A escolha, entretanto, deve considerar o custo de manter o SQL, testar os resultados e acompanhar alterações no esquema.

10. É possível utilizar EF Core e Dapper no mesmo projeto?

Sim.

EF Core e Dapper não precisam ser tratados como alternativas mutuamente exclusivas.

Uma aplicação pode utilizar EF Core para as operações de persistência mais comuns e Dapper para consultas específicas que se beneficiem de SQL explícito.

Por exemplo, um sistema de gestão pode utilizar EF Core para cadastrar clientes, atualizar pedidos e manter relacionamentos entre entidades.

Ao mesmo tempo, um módulo de relatórios pode utilizar Dapper para executar consultas específicas que retornam DTOs.

Essa abordagem híbrida permite aproveitar os recursos de cada ferramenta.

Entretanto, ela também aumenta a quantidade de tecnologias que a equipe precisa conhecer e manter.

Antes de adotar as duas, vale verificar se a complexidade adicional é justificada pelos requisitos do sistema.

Um exemplo de separação de responsabilidades

Uma estrutura possível seria:

MinhaAplicacao
├── Domain
│   ├── Entities
│   └── Interfaces
├── Application
│   ├── UseCases
│   └── DTOs
├── Infrastructure
│   ├── Persistence
│   │   ├── AppDbContext.cs
│   │   └── Repositories
│   └── Queries
│       └── RelatoriosQueries.cs
└── Api
    └── Controllers

Nessa organização, o EF Core pode ser utilizado na implementação dos repositórios e o Dapper pode ficar concentrado em consultas específicas.

A estrutura é apenas um exemplo. O desenho real deve refletir o tamanho do projeto e as necessidades da equipe.

Também é importante evitar duplicação desnecessária de responsabilidades, como implementar a mesma consulta de duas maneiras sem uma justificativa clara.

11. O que considerar em aplicações com alto volume de dados?

Em aplicações que trabalham com grande quantidade de registros, a estratégia de acesso aos dados precisa ser avaliada com mais cuidado.

A primeira etapa não deve ser escolher automaticamente o Dapper.

É necessário identificar onde está o gargalo.

O problema pode estar em:

Consultas sem índices adequados.
Paginação ineficiente.
Retorno excessivo de colunas.
Carregamento desnecessário de relacionamentos.
Múltiplas viagens ao banco.
Bloqueios e contenção.
Uso excessivo de memória.
Limites de conexão.
Concorrência elevada.
Operações de escrita em grande escala.

Em determinados cenários, o Dapper pode oferecer uma vantagem mensurável.

Em outros, a otimização do SQL gerado pelo EF Core pode resolver o problema sem introduzir outra biblioteca na arquitetura.

Também vale considerar recursos específicos do EF Core, como consultas sem rastreamento e pooling de contextos, quando apropriados.

A recomendação é medir o comportamento real da aplicação antes de realizar mudanças estruturais.

12. Como tomar a decisão na prática?

Uma forma simples de decidir é avaliar cada operação de acesso aos dados individualmente.

Cenário	Escolha inicial recomendada
CRUD convencional com entidades relacionadas	EF Core
Aplicação com forte utilização de LINQ	EF Core
Persistência com rastreamento de alterações	EF Core
Migrações gerenciadas pelo framework	EF Core
Relatório com SQL específico e projeções próprias	Dapper pode ser adequado
Consulta complexa com SQL já otimizado	Dapper pode ser adequado
Sistema em que a equipe precisa de controle explícito do SQL	Dapper pode ser adequado
Aplicação que exige as duas abordagens em áreas distintas	Avaliar uma estratégia híbrida

A tabela serve como ponto de partida, não como uma regra absoluta.

O EF Core também permite SQL explícito, e o Dapper pode ser utilizado em aplicações com diferentes níveis de complexidade.

A decisão final deve levar em conta os requisitos, a experiência da equipe, a facilidade de manutenção e os resultados dos testes.

13. Como medir o desempenho antes de decidir?

Se a motivação para escolher Dapper for desempenho, estabeleça um teste reproduzível.

Uma abordagem prática é:

Selecionar uma consulta real da aplicação.
Criar uma versão equivalente utilizando EF Core.
Criar uma versão equivalente utilizando Dapper.
Executar ambas contra o mesmo banco de dados.
Utilizar dados representativos do ambiente de produção.
Medir latência, alocações de memória e uso de CPU.
Repetir os testes para reduzir o impacto de variações ocasionais.
Avaliar o resultado sob diferentes níveis de concorrência.
Comparar a complexidade e o custo de manutenção de cada implementação.

É importante garantir que as duas versões retornem os mesmos dados e executem operações equivalentes.

Também é necessário distinguir o tempo gasto no banco do tempo de processamento realizado pela aplicação.

Sem essa separação, uma diferença observada pode ser atribuída incorretamente à biblioteca utilizada.

Ferramentas de profiling, logs de consultas e planos de execução podem ajudar a identificar as causas reais dos problemas.

Conclusão

EF Core vs Dapper não é uma disputa em que uma ferramenta precisa vencer em todos os cenários.

O Entity Framework Core oferece um conjunto abrangente de recursos para mapear entidades, construir consultas com LINQ e gerenciar a persistência. Isso pode aumentar a produtividade e facilitar a manutenção de aplicações com modelos de domínio e relacionamentos complexos.

O Dapper oferece uma abordagem mais enxuta para executar SQL e mapear resultados. Ele pode ser especialmente útil quando o controle explícito das consultas é importante ou quando existem operações específicas que justificam essa escolha.

Em relação ao desempenho, o Dapper pode apresentar menor overhead em determinadas situações, mas isso não garante que será mais rápido em todas as aplicações. O SQL executado, os índices, a quantidade de dados e o tempo de acesso ao banco continuam sendo fatores fundamentais.

Para muitos projetos .NET, começar com EF Core é uma escolha razoável. Se uma consulta específica apresentar problemas, a equipe pode investigar o SQL, otimizar o acesso aos dados e avaliar se Dapper oferece uma vantagem real.

Em aplicações maiores, também é possível combinar as duas ferramentas, desde que exista uma separação clara de responsabilidades.

A melhor decisão é aquela que equilibra desempenho, produtividade e manutenção, com base nas necessidades reais do sistema e não apenas em benchmarks isolados.