Embed Size (px)
Citation preview
1
PERSISTÊNCIA DE DADOS: UM COMPARATIVO DE DESEMPENHO
ENTRE ENTITY FRAMEWORK E DAPPER
Jefferson Tony Rodrigues Pigossi1
Renata Mirella Farina2
Resumo
Este artigo tem como objetivo analisar e comparar os frameworks Entity Framework e Dapper
no aspecto de desempenho, fornecendo assim ao desenvolvedor uma escolha correta. Os
testes foram realizados através de um software desenvolvido na plataforma Visual Studio
Community, na linguagem de programação C# (Csharp) e utilizando banco de dados SQL
Server Express. Através de inserções, consultas, alterações e exclusões de informações
contidas dentro de um banco de dados e com variações de quantidades de cinquenta, mil e
cinco mil registros. Ao comparar o tempo de resposta de cada operação será possível
evidenciar qual ferramenta possui um melhor desempenho.
Palavras-chave: Entity Framework. Dapper. Framework. Desempenho.
DATA PERSISTENCE: A PERFORMANCE COMPARATIVE BETWEEN ENTITY
FRAMEWORK AND DAPPER
Abstract
This article aims to analyze and compare the Entity Framework and Dapper frameworks in
the aspect of performance, thus providing the developer with a correct choice. The tests were
performed using software developed on the Visual Studio Community platform, in the C #
programming language (Csharp) and using the SQL Server Express database. Through
insertions, queries, changes and exclusions of information contained within a database and
with variations of quantities, fifty, thousand and five thousand records. By comparing the
response time of each operation it will be possible to show which tool has the best
performance.
Key-words: Entity Framework. Dapper. Framework. Performance.
1 INTRODUÇÃO
Com o avanço frenético da tecnologia, o desenvolvimento de software e aplicativos se
torna obrigatório, em uma sociedade na qual o tempo é prioridade e os registros devem ser
1 Graduando do Curso de Sistema de Informação da Universidade de Araraquara- UNIARA. Araraquara-SP. E-
mail: [email protected]
2 Orientador. Docente Curso de Sistema de Informação da Universidade de Araraquara- UNIARA. Araraquara-
SP. Mestre em Engenharia de Produção, USP, EESC. E-mail: [email protected]
2
armazenados e recuperados rapidamente e com integridade. Essas informações muitas das
vezes são enormes, com milhões de registros, e podem ser comparadas a uma instituição
financeira, na qual um simples erro pode gerar vários prejuízos financeiros, esses registros
costumam ser salvos em Banco de Dados Relacionais, e assim organizados em tabelas
bidimensionais (denominadas relações) com colunas e linhas (KENNETCH; JANE, 2011).
Com a concepção do paradigma de Programação Orientada a Objetos (POO) que “foi
criada para tentar aproximar o mundo real do mundo virtual: a ideia fundamental é tentar
simular o mundo real dentro do computador. Para isso, nada mais natural do que utilizar
objetos, afinal, nosso mundo é composto de objetos” (MONQUEIRO, 2007).
O POO diverge do conceito do modelo de Banco de Dados Relacional, como citado
anteriormente, com objetivo de adaptar esses modelos foram a obrigatoriedade de desenvolver
framework que demandam, e fazem com que POO uma relação dos objetos com as
informações que os mesmos representam dentro do banco de dados. Essas ferramentas são
chamadas de mapeamento objeto-relacional (Object Relational Mapping ou ORM), que
permitem ao desenvolvedor uma maneira transparente de um padrão para o outro, trazem para
o POO muitas propriedades que antes eram feitas com muitas linhas confusas e extensas
ocasionando resultados incorretos (DEVMEDIA, 2011).
O objetivo desse trabalho é desenvolver um software em C# (Csharp) utilizando a
framework ORM Entity Framework e Dapper com banco de dados SQL Server Express para
realizar operações básicas como (inserção, atualização, consulta e exclusão) em grande
quantidade, de tal modo comparando o tempo de resposta de cada operação e assim avaliar
qual framework apresenta melhor desempenho.
Quando se trata de persistência de dados muitas ferramentas ORM estão disponíveis,
cada um com seus padrões e características, porém um projeto pode exigir algo específico
como maior desempenho, esse artigo ajuda ao desenvolvedor a decidir qual usar.
Nos tempos atuais no qual todos os processos de empresas, organizações, governos e
indústrias já são automatizados e armazenados em banco de dados, na própria internet, os
dados não param de aumentar. Segundo um estudo (2012) “A Universe of Opportunities and
Challenges” desenvolvido pela consultoria EMC prevê que até o ano de 2020 o volume de
dados circulantes no mundo atingira 40 zettabytes ou 40 trilhões de gigabytes, por isso a
manipulação de informações contidas em um banco tem que ser o mais rápido possível, a
escolha do melhor framework que faz essa manipulação (ORM) se torna primordial, o que
justifica esse trabalho.
3
Com tantas ferramentas de ORM no mercado, o desenvolvedor ou empresa tende a
escolher os mais famosos, contudo às vezes não preenchem os requisitos necessários, imagine
uma seguinte situação, um caixa de supermercado, em que cada produto que é passado pelo
leitor de código de barras, demorasse vários segundos para serem contabilizados no pedido,
isso geraria filas e vários problemas. Artigos como esse são realizados para fazerem a análise
e comparação de velocidade entre framework, induzindo o programador a escolha apropriada
para seu projeto.
2 REVISÃO BIBLIOGRÁFICA
Nessa sessão será realizado a apresentação das tecnologias, ferramentas que foram
utilizados nesse artigo.
Para desenvolver o software que realiza os testes foram utilizados o Visual Studio,
segundo o website oficial da Microsoft (2018a), Visual Studio é uma IDE (ambiente de
desenvolvimento integrado) um programa repleto de recursos que pode ser usado por muitos
aspectos do desenvolvimento de software. Além do editor e do depurador padrão no qual é
fornecido pela maioria das IDEs o Visual Studio inclui compiladores, ferramentas de
preenchimento de código, designers gráficos e muitos outros recursos para facilitar o processo
de desenvolvimento de software.
Há várias versões dessa IDE, entretanto, para desenvolver o programa que executa os
testes de comparação foi utilizado a versão Visual Studio Community 2017 cuja sua licença é
gratuita.
A Linguagem de programação escolhida foi a C# de acordo com website oficial da
Microsoft (2016b), C# (pronuncia-se “C Sharp”) é uma linguagem de programação simples,
moderna, orientada a objeto e fortemente tipado. O C# tem suas raízes na família de
linguagem C.
Para persistir os dados o banco escolhido foi o SQL Server Express ele é uma variante
do sistema gerenciamento de banco de dados SQL Server da Microsoft que é gratuito.
SQL Server é um banco de dados relacional destinado a suportar aplicações, com
arquitetura cliente/servidor em que o banco de dados fica residente em um
computador chamado central cujas as informações são compartilhadas por diversos
usuários que executam as aplicações em seus computadores locais, ou cliente.
(RAMALHO, 2005, p. 1).
Um framework é uma biblioteca ou conjunto de códigos que aplica os padrões que já
resolvem maior parte das implementações que acontecem frequentemente em determinada
categoria de software, segundo GAMMA et al. (2007, p.42) um “framework dita a arquitetura
4
da sua aplicação. Ele irá definir a estrutura geral, sua divisão em classes e objetos e em
consequência as responsabilidades-chave das classes de objetos”.
O Entity Framework é um framework de acesso a dados (ORM) da Microsoft
(atualmente open source) para criar aplicativos .NET. Foi lançado em julho de 2008 como
componente do Visual Studio 2008 Service Pack I e .NET 3.5 Service Pack I, dois anos
posteriormente a Microsoft ter anunciado na Conferência de TechEd 2006. (LERMAN,
2009).
O EF6 ou Entity Framework 6 (verão atual), segundo a documentação da Microsoft
(2016c), o EF6 minimiza a falta de compatibilidade de impedância entre os bancos de dados
relacionais e orientação a objeto, portanto permitem que programadores desenvolvam
aplicativos, assim interagindo com os dados armazenados, usando objetos do Microsoft .NET
no qual são fortemente tipados e representam o domínio do aplicativo, do mesmo modo
eliminando a necessidade de uma grande parte do acesso aos dados, diminuindo o código que
normalmente os programadores necessitariam para escrever. A figura 1 abaixo apresenta a
arquitetura utilizada pelo EF6.
Figura 1 - Arquitetura EF6. FONTE: (MSDN, 2014)
Um dos benefícios do EF6 é o suporte ao uso do LINQ (Language Integrated Query),
que permite ao desenvolvedor escrever consultas usando formas declarativas parecidas com
SQL ou expressões lambdas, “uma expressão lambda é um bloco de código (uma expressão
ou um bloco de instrução) que é tratado como um objeto” (MICROSOFT,2019?d), ao banco
de dados, com a própria linguagem de programação, como C#, ao invés de usar a linguagem
tradicional de banco de dados. Essa condição de abordagem evita extensos códigos confusos e
5
com uma chance maior de causar erros, além disso, permite ao EF6 fazer a consulta de uma
maneira mais eficaz.
O Micro ORM são frameworks que mapeiam os dados relacionais para objetos, mas
não possuem todos os recursos de um ORM tradicional, a ideia do micro ORM é
precisamente dar uma opção intermediária entre produtividade e performance. Eles trazem
parte das funcionalidades de mapeamento objeto-relacional do ORM, mas sem implementar
muitas funcionalidades (muitas vezes pouco utilizadas) que acabam os deixando mais lentos.
(LIMA, 2017).
O framework Dapper é um framework de persistência de dados micro ORM,
desenvolvido Marc Gravell e Sam Saffron enquanto trabalhavam no Stack Overflow (um
website destinado a perguntas e resposta para programadores), posteriormente foi
disponibilizado para comunidade como um software de código aberto (open source), ele é
voltado para o desenvolvimento de soluções Microsoft.NET (LERMAN, 2016).
O foco justamente do Dapper é desempenho, diferente do framework ORM, que
geram automaticamente uma query ou comandos mais complexos, nesse caso simplesmente é
passado diretamente comandos SQL puro, na prática o Dapper disponibiliza a Extension
Methods que trabalha com objetos de conexão ADO.NET, assim dando a oportunidade ao
desenvolvedor para otimizar o código e obtendo resultado mais veloz, assim tornando sua
aplicação mais rápida.
Segundo Croffer (2017), o Dapper consegue fazer implementação da interface
IDbConnection, este atributo permite que ele possa ser utilizado para acessar qualquer
tecnologia relacional compatível com o Microsoft.NET, SQL Server, Oracle, PostgreSQL e
MySQL são alguns exemplos de banco de dados possíveis.
3 DESENVOLVIMENTO
O contexto desse trabalho é evidenciar o tempo de resposta da execução de cada tipo
de operação com os frameworks de persistência de dados Entity Framework e Dapper. O
menor tempo de resposta determina qual framework apresenta melhor desempenho, são
operações comuns dentro do mundo de desenvolvimento, onde há troca de informação com
bancos de dados, criação, consulta, atualização e destruição de informações, essas operações
são mais conhecidas como GRUD (Create, Read, Update e Delete), cada tipo de operação foi
executado quatro vezes e com quantidades variáveis de cinquenta, mil e cinco mil registros,
posteriormente calculado a média e apresentado os resultados para análise.
6
A metodologia de pesquisa utilizada foi a de uma abordagem quantitativa, os
resultados da pesquisa podem ser quantificados, ou seja, sua principal característica é analisar
números, gráficos, tabelas e dados recolhidos com auxílios de instrumentos padronizados e
imparciais. A pesquisa quantitativa recorre a linguagem matemática para descrever relações
entre variáveis (FONSECA, 2002).
Foram aplicados o método de pesquisa experimental, executando as operações e
obtendo resultados no tempo de segundos, a cada teste realizado a variável quantidade de
registros foi alterado. A pesquisa permitirá analisar e interpretar os dados com métricas de
desempenho.
Parte-se da hipótese de que o framework Dapper é mais rápido que o Entity
Framework nas operações, pois possui menos recursos de implementação, que dificultam o
desenvolvimento, no qual conseguem executar com um maior desempenho.
Para garantir a integridade do resultado, o software oferece o mesmo cenário de
hardware, ou seja, executado sempre no mesmo computador e com mesmo estímulos de
tempo, também sempre foi seguido o mesmo protocolo de cliques em ambos os frameworks, a
diferença fica exclusivamente para a escrita de programação. O computador utilizado foi um:
Intel® Core™ i5-3230M 2.60GHz, 16 GB RAM, 240GB SSD e Windows 10.
A seguir será detalhado as operações que serão executadas, justamente com as
quantidades:
Inserção: será realizado as inserções de registros através do sistema
desenvolvido, as quantidades serão variadas, contendo cinquenta, mil e cinco
mil registros, todos serão salvos dentro do banco de dados que será criado. Os
dados a ser inseridos serão iguais, com todos os campos da tabela preenchida.
Consulta: será realizado consultas através do sistema, as mesmas em
quantidades diferentes, cinquenta, mil e cinco mil registros. Todos consultados
dentro do banco de dados.
Alteração: será realizado alterações de registro através do sistema, alterações
em quantidades diferentes de cinquenta, mil e cinco mil, todos alterados na
tabela que será criada.
Exclusão: será realizado exclusão de registros com as quantidades variando de
cinquenta, mil e cinco mil registros, através do sistema.
7
Ao fim de cada operação o tempo de execução em segundos é salvo dentro de uma
tabela no banco de dados chamada resultados, juntamente com tipo de operação e framework
utilizada.
Para medir o tempo de execução de forma que garanta a integridade dos resultados, foi
utilizado uma classe chamada Stopwatch, essa classe fornece um conjunto de métodos e
propriedades que medem o tempo decorrido de maneira precisa, essa classe faz parte do
Microsoft.NET (Microsoft, 20??e). Abaixo na figura 2 é demonstrado como que a classe é
executada, o comando sw.Star() inicializa o tempo (ele é executado anteriormente da
execução principal), e o comando sw.Stop() é quando o tempo é pausado (posteriormente a
execução principal), no código sw.Elapsed() é onde fica o tempo percorrido da execução
principal e para finalizar o comando TotalSeconds, onde é extraído o tempo em segundos.
Figura 2 - Comandos para medição do tempo em segundos. FONTE: Autor.
Foi desenvolvido um software com a interface de desenvolvimento (IDE) Visual
Studio 2017 Community para demonstrar e auxiliar as operações efetuadas, foi utilizado a
mesma base para todas as operações, são elas: linguagem de programação C# com telas
Windows Forms. São quatro telas (abas), cada tela com um tipo de operação e suas
respectivas variações de quantidades, para cada botão foi escrito um comando específico com
a framework e de acordo com as variações de quantidade proposta por esse artigo, como
mostrado na figura 3.
8
Figura 3 - Abas do software. FONTE: Autor
Foi desenvolvido um banco de dados no SGDB (Sistemas de Gestão de Base de
Dados) SQL Server, na figura 4 é evidenciado o modelo de dados chamado Artigo. A tabela
PessoasDapper e PessoasEntityF são idênticas, com os seguintes campos: Id do tipo inteiro
ou numérico, Nome do tipo texto, CPF do tipo texto, Telefone do tipo texto e
Codigo_Estado_Civil do tipo inteiro ou numérico, somente os nomes das tabelas são
diferentes. Essas tabelas é onde os dados serão inseridos e em seguida consultados, alterados e
excluídos, nessa ordem, cada uma com seu respectivo framework.
A tabela EstadoCivil faz um relacionamento de 1..n (um para muitos) com o campo
Codigo_Estado_Civil das tabelas PessoasDapper e PessoasEntityF.
Por fim temos a tabela Resultados, o campo framework é do tipo texto e será
armazenado qual framework foi utilizada (Entity Framework ou Dapper), o campo operação é
do tipo texto, no qual será armazenado o tipo de operação que foi executada (inserções,
consulta, alteração e exclusão), o campo tempo_inicio do tipo Time é salvo o tempo de início
da execução, o tempo_final é do tipo Time, onde o tempo depois da execução é armazenado. E
por fim o campo tempo_liquido do tipo Time é armazenado a diferença do tempo em
segundos, do início e do final da execução.
9
Figura 4 - Modelo de Dados. FONTE: Autor
Todos os comandos escritos para realização dos testes são listados logo abaixo, é
essencial evidenciar a programação de cada tipo de operação e suas diferenças básicas entre
os frameworks.
Abaixo na figura 5, é ilustrado o código de inserção do framework Entity Framework,
nos quais são inseridos cinquenta registros, dito anteriormente existe também comandos para
inserção para mil e cinco mil registros. Pode-se observar que não há complexidade no código,
é de maneira sucinta. Isso acontece devido ao fato do Entity Framework utilizar o uso do
LINQ que permite ao desenvolvedor escrever comandos na própria linguagem de
programação, deixando uma menor preocupação com o banco de dados.
Figura 5 - Código de inserção, Entity Framework. FONTE: Autor
Na figura 6 é o código escrito utilizado pelo framework Dapper, fica claro a diferença
de quantidade de código, exige mais atenção e principalmente mais tempo para escrever, isso
acontece pelo fato do Dapper utilizar SQL Puro. Os comandos em vermelho são comandos
SQL que formam uma query. O query é um conjunto de instruções em SQL utilizado para
manipular alguma informação no banco de dados. O que acontece posteriormente é a
vinculação das variáveis a seus respectivos valores.
10
Figura 6 - Código de inserção, Dapper. FONTE: Autor
Para realizar as consultas, ambos os frameworks trazem todos os valores dos campos
da tabela, juntamente com o relacionamento que está associado ao Codigo_Estado_Civil, com
a tabela EstadoCivil. Quando se tem algum relacionamento entre tabelas, essa junção quando
realizada, diminui o desempenho, isso ajuda a definir qual dos frameworks executa mais
rápido. Na figura 7 se refere ao Entity Framework, pode se observar um código extenso, na
falta de prática do LINQ com expressão lambda que se torna mais complexo e confuso, suas
consultas são geradas por um provider (um núcleo) que não pode ser alterado. Foi adicionado
um filtro ou uma condição, para trazer um limite específico de registros para atender ao
cenário de teste proposto, nesse caso o campo ID tem que ser (>=1) e (<=50), consultando 50
registros.
Figura 7 - Consulta com Entity Framework. FONTE: Autor
Na figura 8 é evidenciado a consulta com o Dapper, nesse caso a complexidade se
inverteu, com menos linhas de programação e de fácil entendimento comparado com Entity
Framework. O Dapper não possui métodos específicos para cada operação básicas (GRUD),
para consultar o comando utilizado, é o Query().
11
Figura 8 - Consulta com Dapper. FONTE: Autor
No caso das alterações o campo escolhido para ser alterado foi o Nome, seu valor é
alterado para ALTERADO COM SUCESSO, na figura 9 é evidenciado o código da Entity
Framework, que traz todos os registros determinados pelo filtro, no caso os primeiros
cinquentas registros. Um detalhe que deve ser observado, é que depois da consulta ele precisa
percorrer por todos os registros, alterando os campos e só assim executar o comando
SaveChanges para persistir os dados na base de dados.
Figura 9 - Alteração, Entity Framework. FONTE: Autor
No ponto de alterações ambos os frameworks têm os códigos parecidos em questão de
quantidade e complexidade, na figura 10 segue o código do Dapper, em que é passado uma
query para o comando execute().
Figura 10 - Alteração, Dapper. FONTE: Autor
A exclusão também foi realizada com os mesmos filtros das outras operações, nos dois
frameworks. Na figura 11 podemos observar o código com Entity Framework, primeiro ele
seleciona todos os registros da tabela conforte determina o filtro e depois ele percorre registro
a registro para excluir e só posteriormente salva as exclusões no banco de dados.
Figura 11 - Exclusão com Entity Framework. FONTE: Autor
No caso de exclusões com o Dapper, ele utiliza somente uma query e os comandos já
são salvos no banco de dados, como mostrado na figura 12.
12
Figura 12 - Exclusão com Dapper. FONTE: Autor
4 RESULTADOS
Nessa sessão é ilustrado os resultados das comparações e a discussão de cada tipo de
operação, sendo executado quatro vezes, exceto a exclusão, pois o registro passa a não
existir.
Após as quatros operações é calculado a média aritmética.
Figura 13 - Tempo de execução em segundos. FONTE: Autor
Na figura 13 é mostrado os resultados de tempo de resposta das inserções, dos
frameworks Entity Framework e Dapper.
Nas inserções de cinquenta registros o Entity Framework apresenta um tempo de
0,3164s e o Dapper 0,0341s. O Dapper apresentou menor tempo de resposta com uma
diferença de 0.2823s.
Nas inserções de mil registros o Entity Framework apresenta um tempo de resposta de
3,9756s e o Dapper 0,3250s, fica evidenciado um menor tempo para o Dapper com uma
diferença de 3.6506s.
Nas inserções de cinco mil registros, temos o tempo do Entity Framework de 19,9106s
e o Dapper de 1,6244s, com uma diferença considerável de 18.2962s. O Dapper apresentou
menor tempo de execução.
Destaque-se o amplo aumento de tempo do Entity Framework, conforme a quantidade
que foi alterada.
13
Figura 14 – Tempo de execução das consultas em segundos. FONTE: Autor
Na figura 14 é demonstrado os resultados das operações de consultas com ambos os
frameworks.
Nas consultas de cinquenta registros, o Entity Framework obteve tempo de resposta de
0,1632s, e o Dapper de 0,0236s, com uma diferença de 0,1396s que mantem o Dapper com
menor tempo.
As de mil registros, o Entity Framework apresentou o tempo de 0,0106s, e o Dapper
apresentou o tempo de resposta de 0,0092s, com uma diferença mínima de 0,0014s, mas que
mantem o Dapper com menor tempo.
Percebesse que nas consultas de cinquenta registros o tempo foi maior, mesmo sendo
uma quantidade menor de consultas, isso advém porque ambos os frameworks fazem o uso da
memória em cache do computador, mantendo consultas gravadas para que o esforço seja
reduzido em caso de repetição de consultas.
Nas de cinco mil registros, o Entity Framework obteve o tempo de 0,0501s, e o
Dapper de 0,0379s evidenciando novamente o menor tempo de resposta, com uma diferença
de 0,0110s.
14
Figura 15 - Resultado do tempo de resposta das alterações em segundos. FONTE: Autor
Na figura 15 segue os resultados de tempo de resposta das alterações, com os
frameworks Entity Framework e Dapper.
As alterações de cinquenta registros, o Entity Framework teve um tempo de resposta
de 0,2244s, e o Dapper de 0,0132s, concluindo que o Dapper leva menos tempo com uma
diferença de 0,2112s.
Nas alterações de mil registros o tempo de resposta do Entity Framework foi de
0,5077s, e o Dapper apresentou um tempo de 0,0043s, novamente com uma diferença de
0,5033s.
Com alterações de cinco mil registros, o Entity Framework concluiu com o tempo de
1,8684s, e o tempo do Dapper foi de 0,0151s, assim Dapper com uma diferença de 1,8533s foi
executado com menor tempo.
Figura 16 - Resultado do tempo de resposta das exclusões em segundos. FONTE: Autor.
15
Na figura 16 fica evidenciado os resultados de tempo de resposta das exclusões, com
os frameworks, com o tempo em segundos.
As exclusões de cinquenta registros, o Entity Framework teve um tempo de resposta
de 0,6607s, o Dapper demorou 0,0427s, concluindo que o Dapper teve um menor tempo com
uma diferença de 0,6181s.
Nas Exclusões de mil registros Entity Framework obteve o tempo de 1,8190s, e o
Dapper de 0,0039s, dando ao Dapper melhor desempenho com uma diferença de 1,8151s.
Por fim nas exclusões de cinco mil registros, o Entity Framework teve um tempo de
resposta de 35,6654s, e o Dapper de 0,0119s, com um tempo consideravelmente de diferença
de 35,6534s, assim o Dapper obteve um melhor resultado.
Figura 17 - Resultado do tempo de resposta de todas as execuções em segundos. FONTE: Autor.
Na figura 17 é informado a média de cada tipo de execução utilizando inserções,
consultas, alterações e exclusões de todas realizadas nesse artigo.
Nas operações de inserções pode-se observar uma média do Entity Framework de
8,0675s e de 0,6612s da framework Dapper.
Em consultas, o Entity Framework conseguiu uma média de execusão de 0,0739s, e o
Dapper com 0,0232s.
As alterações foram executadas com o Entity Framewok com um tempo médio de
0,8668s e o Dapper 0,0109s.
Por fim o tempo médio das exclusões com o Entity Framewoek foi de 12,7151s, e o
Dapper com 0,0195s.
16
5 CONCLUSÃO
O propósito desse artigo foi realizar teste de comparação de desempenho com as
operações básicas (inserção, consulta, alteração e exclusão) entre framework de persistência
de dados, no caso Entity Framework e o Dapper, o maior problema é que esse tipo de
ferramenta existe em abundância no mercado. As possibilidades são muitas, cada framework
oferece suas características e cada tipo de projeto tem suas necessidades. Há vários trabalhos
como esses, entretanto notei a ausência de mais detalhes relacionados a códigos escritos
(programação), ambos os frameworks utilizam maneiras diferentes para executar as mesmas
operações, além disso, as operações foram executadas com três quantidades diferentes e cada
operação executada quatro vezes e foi feito uma média dos resultados.
Pela observação das comparações é evidenciado o maior desempenho médio com o
framework Dapper no quesito de inserções, em relação ao Entity Framework. A diferença ao
inserir cinquenta registros foi de 0,2824s, de cinco mil registros foi de 3,6507s e de cinco mil
registro foi de 18,2861s. No quesito consulta o Dapper também obteve um menor tempo de
execução, ao consultar cinquenta registros a diferença foi de 0,1396s, de cinco mil registros
foi de 0,0014s e de cinco mil foi de 0,0110s. Em alterações o Dapper também foi o mais
rápido, com uma diferença de 0,2112s quando foi alterado cinquenta registros, com mil
registros a diferença foi de 0,5033s e com cinco mil registros alterados foi de 1,8533s. Por fim
nas execuções de exclusões o Dapper continuou com menor resultado, ao excluir cinquenta
registros a diferença foi de 0,6181s, para excluir mil registro foi de 1,8151s e para excluir
cinco mil registros a diferença foi de 35,6534s.
O Dapper obteve melhor performance em todas as operações realizadas, porém a
diferença maior com o Entity Framework permaneceu com as operações de inserções e
exclusões, com uma diferença dez vezes mais rápida, nas operações de consultas e alterações
a diferença é menor, em certos momentos dos testes a diferença nem foi notada, somente nos
números.
A hipótese levantada nesse artigo foi que o Dapper seria mais rápido porque faz menos
implementações e consequentemente executando um melhor desempenho, e foi justificado
por meios de comparações e análises.
Vale lembrar que com o Entity Framework o tempo de desenvolvimento foi menor,
pois a framework oferece facilidades de implementação com a ajuda do LINQ e expressões
lambdas. Contudo, essa maior flexibilidade tem um custo de desempenho nas operações,
como podemos observar.
17
Mesmo com o ganho do Dapper nada impede que ambos os frameworks sejam usados
em conjunto, para cada tipo de necessidade se o projeto necessitar.
Para uma futura evolução desse trabalho, pode-se realizar as mesmas operações,
porém em uma rede de computadores, no qual existe um computador central (servidor),
servindo as informações a outros computadores (terminais).
6 REFERÊNCIAS
DEVMEDIA. ORM: Object Relational Mapper. Disponível em
<https://www.devmedia.com.br/orm-object-relational-mapper/19056> Acesso em 27
fev.2019.
FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza: UEC, 2002. Apostila.
GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de
projetos: Soluções reutilizáveis de software orientando a objetos. 1 ed. São Paulo:
Bookman, 2007.
GANYZ, John; REINSEL, David. A Universe of Opportunities and Challenges. Disponível
em: <https://www.emc.com/collateral/analyst-reports/idc-the-digital-universe-in-2020.pdf>
Acesso em 14 mai.2019.
GROFFE, Renato. Dapper: relacionamentos Um-para-Um e Um-para-Muitos. Disponível
em: <https://medium.com/@renato.groffe/dapper-relacionamentos-um-para-um-e-um-para-
muitos-exemplos-em-asp-net-core-cfb0bf0668> Acesso em 13 mar.2019.
LAUDON C, Kenneth; LAUDON P, Jane. Sistemas de informação gerenciais. 11 ed. São
Paulo: Pearson Education, 2014.
LERMAN, Julia. Programming Entity Framework: Building Data Centric Apps with the
ADO.NET Entity Framework. 2 ed. EUA: O’Reilly Media, 2010.
LERMAN, Julie. Pontos de Dados – Dapper, EntityFramework e Aplicativos Híbridos.
Disponível em: <https://msdn.microsoft.com/pt-br/magazine/mt703432.aspx> Acessado em
11 mai.2019,
LIMA, A André. Introdução ao Dapper. Disponível em:
<http://www.andrealveslima.com.br/blog/index.php/2017/10/04/introducao-ao-dapper/>
Acesso em 13 mar.2019.
MICROSOFT. Bem-vindo ao IDE do Visual Studio. [2018a]. Disponível em
<https://docs.microsoft.com/pt-br/visualstudio/get-started/visual-studio-
ide?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3D
Dev15IDEF1%26l%3Dpt-
BR%26k%3Dk(MSDNSTART)%26rd%3Dtrue%26f%3D255%26MSPPError%3D-
2147217396&view=vs-2017> Acesso em 01 mar.2019.
MICROSOFT. Um tour pela linguagem C#. [2016b]. Disponível em
<https://docs.microsoft.com/pt-br/dotnet/csharp/tour-of-csharp/> Acesso em 07 mar.2019.
18
MICROSOFT. Entity Framework 6. [2016c]. Disponível em:
<https://docs.microsoft.com/pt-br/ef/ef6/> Acesso em 09 mar.2019.
MICROSOFT. Lambda expressions (C# Programming Guide). [2019?d]. Disponível em: <
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-
operators/lambda-expressions> Acesso em 14 mai.2019.
MICROSOFT. Stopwatch Class. [20??e]. Disponível em: < https://docs.microsoft.com/pt-
br/dotnet/api/system.diagnostics.stopwatch?view=netframework-4.8> Acesso em 11
mai.2019.
MONQUEIRO, B Júlio. Programação Orientada a Objetos: uma introdução. Disponível
em <https://www.hardware.com.br/artigos/programacao-orientada-objetos/> Acesso em 16
abr.2019.
RAMALHO A, José. Microsoft SQL Server 2005: Guia Prático. 1 ed. Elsevier, 2005.
