Skip to content

Entity Framework Core 2.0 mais performático que o Dapper?

Com o Entity Framework Core 2.0 mais performático, resolvi fazer um benchmark comparando com o Dapper através do pacote benchmarkdotnet

.Net Core 2.0 saiu ontem e muita coisa foi melhorada em relação ao Core 1.0, entre essas alterações está a performance do Entity Framework Core 2.0. Pensando nisso eu resolvi fazer um benchmark para ver se é verdade sobre a performance em relação ao Dapper.

Para quem não conhece o Dapper eu aconselho a conhecer. Ele é um micro ORM, não tem tudo o que um EF ou NHibernete tem, mas em relação a consultas ele é bastante rápido. Nos últimos anos é normal ver um projeto que tenha um ORM e o Dapper sendo utilizado para otimizar os relatórios.

Voltando no benchmark eu fiz algo bobo, criei uma entidade de produto e uma categoria e seus vínculos é o chamado 1 para 1. Apenas para ressaltar, não sou especialista em benchmark, mas achei legal esse pacote e resolvi utilizar para medir a performance. Se você tem alguma sugestão será bem vindo.

A ideia é simples, comparação de inserção de dados, consulta de dados, e consulta com um filtro especifico. Claro que isso faço em comparação do Entity Framework Core 2.0 com o Dapper.

Abaixo vocês veem o resultado final:

A explicação de cada método é bastante simples:

  • EfInsert e DapperInsert são os métodos de cada ORM para inserção dos dados. Ao mesmo tempo que eu salvo um produto, também salvo a sua categoria.
  • EfSelect e DapperSelect são os métodos que consultam no banco todos os registros. Nesse caso existe uma junção entre as tabelas.
  • EfSelectWithFilter e DapperSelectWithFilter são os métodos que consultam no banco todos os produtos onde o nome da categoria é “Games”.

Notem que em todas as demonstrações o Entity Framework Core 2.0 ganhou. Isso é bom, mostra que o pessoal da Microsoft está realmente cumprindo com o que havia falado a mais de dois anos quando disse que um dos pilares do novo .Net era a performance.

Vale lembrar que o Entity Framework Core 2.0 ainda não tem o mapeamento de muitos para muitos, mas conseguimos contornar esse problema criando a tabela (Entidade) de relacionamento.

Quem ainda tem dúvida em relação a usar ou não o Entity Framework Core 2.0, acredito que agora ele é uma forte opção, começando pela performance. Foi lançado ontem e recomendo  muito você dar uma olhada. Se quiser analisar meu benchmark e quiser acrescentar mais coisa, segue o link https://github.com/StephanyBatista/benchmarkef

Bom, espero ter ajudado e até a próxima.

Você gostou desse artigo? Gostaria de saber mais sobre ASP.NET Core? Eu desenvolvi um curso na Udemy, preço camarada e com mais de 13h de curso. Acesse https://www.udemy.com/aspnet-core-aprendendo-do-zero-ao-avancado/

Published in.Net Core

8 Comments

  1. Alexandre Carneiro Alexandre Carneiro

    Bom artigo !

    Tenho uma certa resistência a migrar pra Dapper em função da necessidade do developer entender das querys que executa ao invés de fazer operações com frameworks como EF ou NHibernate… mas pensando depois a chance de um developer fazer uma consulta sem performance fica maior quando ele usa recursos indevidos numa query com o uso do framework que ao fazer a query primeiro na ferramenta de consulta e depois “copiar” para sua aplicação que usa Dapper….

    Vou considerar fortemente recomendar para minha equipe na próxima iniciativa.

    • stephanybatista stephanybatista

      Legal, bacana!

      Eu acho que dev tem que saber fazer query. Mas isso é eu “acho”.

  2. Show, fiquei contente por usar uma lib de benchmark, gosto muito dela, ela é extremamente poderosa.

    Só achei uma coisa estranha, pelo que eu sei, o Dapper só serve para fazer query, e não insert, update, delete. Sei que isso é possível por meio de extensões de terceiros, mas essas não são oficiais.

    A algum tempo atrás fiz um teste também, porém compartando EF 6.2.3 com Dapper e NH, fiz até um artigo sobre isso: https://medium.com/albertomonteiro/entity-framework-melhorando-performance-para-consulta-readonly-9e6426b70bbd

    Nele tive uma performance quase igual entre Dapper e EF(quando bem configurado).

    Outra questão importante, com Dapper você só tem leitura de dados, e com EF, na abordagem natural, você pode persistir as alterações da entidade com um simples SaveChanges, e como o Dapper é usado para cenário de leitura, o ideal seria configurar o EF para realizar a mesma tarefa, e desligar todas as features que ele tem para outros propósitos.

    • stephanybatista stephanybatista

      Sim, isso mesmo.

      A ideia não é competir, mas sim unir esses dois caras e deixar no projeto.

      Na empresa que eu trabalho, eles usam NHibernet e tiveram que colocar o Dapper para melhorar os relatórios, ficou show.

  3. Humberto Almeida Humberto Almeida

    E em relação ao nhibernate?

    • stephanybatista stephanybatista

      Eu não sei, me parece que ele ainda não funciona para o core.

  4. Murilo Murilo

    Sugiro que vc faca 1 chamada no banco para inserir com o dapper e não 2 como está fazendo.
    No caso do select, não use * para selecionar as colunas, informe todas explicitamente.
    Em caso de ainda estar mais lento, verifique o SQL gerado pelo EF e poste aqui.
    Não use ‘games’ no select com dapper, use parâmetros, @game.
    Outra, faça um teste mais complexo e maior. 5ms para 3ms não é tempo suficiente para dizer q um é mais rápido que o outro.

    • stephanybatista stephanybatista

      Ok, boa dica! Abraços!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *