Dapper vs Entity Framework ou Dapper + Entity Framework, vale a pena usar? (parte 2)
Dando sequência no post anterior, agora veremos como implementar uma solução onde utilizaremos as duas tecnologias juntas (Dapper + Entity Framework).
Para começar, irei partir de um projeto pré-existente onde temos um repositório implementado, recebendo no seu construtor o Contexto, e através dele mesmo, obtemos a string de conexão (linha 24).
Feito isto, temos a string de conexão disponível na classe (poderíamos também trazê-la do config da aplicação, mas aqui ficou mais simples).
Agora já que temos uma connection string, podemos construir métodos onde podemos executar desde simples consultas, como até querys complexas utilizando o Dapper.
Neste exemplo abaixo, temos uma consulta simples, onde buscamos uma lista de uma entidade, chamada “PlaceModel”.
Através do comando QueryAsync, o Dapper é capaz de mapear a consulta realizada para a entidade que foi apontada “<PlaceModel>”.
Nesta situação abaixo, foi utilizado o Dapper para realizar um Insert ! Sério, um insert? mas por que ? devido ao fato de ter que utilizar tipo de dado “geográfico” tipo este que o Entity Framework não manipula, portanto era necessário realizar um processamento sobre os dados para inserí-los no banco, para isto foi utilizada uma procedure
Este é mais um exemplo de consulta, onde foi utilizada uma Procedure e passados os parâmetros, e o Dapper já realizou o mapeamento das informações para uma coleção do tipo LocationModel.
Como neste caso era necessário um processamento diferente, utilizando funções de geografia a consulta obrigou o uso de Procedure.
Além disso, também podemos utilizar o Dapper, para mapeamento objetos, que possuem relacionamento com outros objetos.
No exemplo abaixo, temos a classe “Funcionario” e “Cargo” onde um funcionário possui um cargo, como fazer para carregar esta lista de funcionários e já carregar em sua propriedade o cargo, utilizando uma query única?
A classe possui uma propriedade chamada “Cargo” que é do tipo “Cargo”.
Então para que carreguemos um funcionário e seu cargo, vamos montar uma query especial onde fazemos um artifício específico para que o Dapper possa separar uma entidade, veja nas setas vermelhas, os campos que terão papel de separador
Então na execução da consulta, nós temos que utilizar um comando que realiza um Split, separando as duas entidades, veja que utilizamos os nomes “FUN_ID” e “CG_ID”.
Mas na linha 30, colocamos entre <> os objetos que serão manipulados, veja que o tipo de objeto que a Query retornará é colocado no final (por isso temos 3 objetos).
Aí veja que na linha 33, utilizamos o objeto “cargo” que foi separado na query e o inserimos como uma propriedade “cargo” do objeto “funcio”, e na linha 34 fazemos um return para que este seja o objeto retornado.
Sendo assim, conseguimos realizar pesquisas com mais de 1 entidade sendo manipulada, já utilizei este recurso em um projeto em 2016 onde o ganho de performance foi muito alto e acabou salvando a arquitetura do projeto, existe um limite de 7 objetos para serem manipulados a não ser que se faça esta abordagem deste tópico (link).
Ainda há uma outra forma de obter dados, que é executando 1 query que resulte em 3 retornos distintos, como neste exemplo abaixo presente na documentação da própria biblioteca Dapper.
Se quiser saber mais sobre o assunto, tenho 2 repositórios que deixarei nas referências de onde eu tirei os exemplos postados aqui.
Gostou do artigo? clique no ícone👏e também me siga para ver as próximas publicações !!
Referências:
Documentação oficial do Dapper: Dapper Tutorial (dapper-tutorial.net)
Minha apresentação realizada numa palestra sobre Dapper: DotNetDapperExample/Palestra .NET-Dapper-no-logo.pdf at main · NIZZOLA/DotNetDapperExample (github.com)
Repositórios com demos: NIZZOLA/DotNetDapperExample: Projeto com exemplos de Utilização da Biblioteca Dapper (github.com)
