Já uns bons anos atrás eu tinha abandonado o EF por completo usava apenas Dapper. Mas daí eu precisei desenvolver um sistema novo, e precisava de velocidade e aos poucos eu fui retornando ao EF. E hoje eu estou nessa que vc comentou no vídeo. Eu uso o máximo que dá pra usar em EF, e as coisas críticas eu faço na mão com Dapper. Esse me mostrou ser o melhor cenário.
Realmente eu também tenho a mesma visão, uso o EF telas simples, quando preciso de uma tela que tem que fazer umas consultas mais elaboradas, como 2 ou 3 joins aí já prefiro partir pra views escrita na mão. Tive um projeto onde os dados eram muito grandes em casa base, cerllca de 700 mil registros nas bases maiores, pra esse projetos fizemos pre processemto dos dados e gerando views pra tela consumir o mais mastigado possível, ficou super rápido a parte de tela. Realmente esse é o melhor caminho hj.
Eu como DBA te digo que parte de alguns problemas de performance em algumas aplicações é por conta de ad-hoc executado via ORM. O que chove de queries com parâmetro NVARCHAR é surreal, isso mata o uso dos índices (no SQL Server, no caso), entre outros problemas de performance. Eu como DBA não odeio a ORM, só acho que as configurações de parâmetros e as escolhas das colunas adequadas para o método e afins devem ser feitas com muito cuidado.
Legal demais esse ponto de vista... realmente tem que inspecionar bem, principalmente o código pra gerar o banco nas migrations... me dá agonia as vezes hahahha.. PS:. Dá pra configurar tudo pelo EF, bonitinho, certinho...
Esses dias tive de desenvolver um sistema com Windows Forms no trampo, e na hora de escolha do acesso a dados, levei em conta justamente o que aprendi nos seus cursos, Balta. No final, ficava melhor usar as queries manuais com Dapper, pelo fato de que era justamente isso, muitos dados cruzados. Na hora que pensei nisso usando EF, deu logo um calafrio e resolvi fazer a escolha correta. Valeuzão pelo aprendizado!!
Estou usando o EF com o Dapper no meu trabalho atual. EF pra inclusão e atualização dos dados e para consultas mais simples e Dapper pra consultas mais complexas. Esse foi a solução que os arquitetos de software do time acharam para melhorar o desempenho da aplicação. E em algumas consultas a diferença do uso do Dapper pro EF foi gritante. Justamente porque era mais simples fazê-las em SQL diretamente do que fazê-las no EF. Eu particularmente prefiro fazer as consultas "na mão", mas cada caso é um caso.
Boa balta. Aqui, dependendo da aplicação, usamos os dois. O EF para operações de gravação (insert, delete e update). O EF tem uma grande vantagem sobre o dapper que é o gerenciamento de estado. Isso eh útil particularmente ao persistir agregados. Já o dapper faz o que ele faz de melhor que é ler as informações de forma performática e com maior controle sobre as querys.
Top isso aí, bom senso no uso das tecnologias nos cenários adequados, o grande problema é quando chega um sênior com 50 anos de experiência e coloca uma lei pra usar só Dapper, ADO puro, Store Procedures pra tudo, a conclusão que eu tenho é que essas pessoas estão é procurando o conforto porque não evoluíram, mas condenam um projeto a uma extrema complexidade de manutenção
Tudo depende do tipo de projeto, para aplicações bancárias por exemplo vejo que é usado muito as stored procedures, acredito que seja para dar um nível de segurança ainda maior ao código.
Eu uso Eloquent com Laravel e Hibernete com Java, faço exatamente isso, não uso um ORM em 100% do sistema. Em relatórios por exemplo preciso cruzar diversas informações então trabalho com SQL diretamente, em consultas simples eu uso o ORM, faço da forma como foi explicado ai, dá pra trabalhar com 100% usando SQL direto mas não dá pra trabalhar 100% com ORM porém o ORM facilita bastante em alguns tipos de implementação.
Eu uso os dois EF e Dapper, tenho sistema inteiro usando EF e outros só usando Dapper, gosto de usar o Dapper quando pego sistemas legados onde a base não está tão bem estruturada.
Uso o EF com migrations no automatic. Amooooooo. É maravilhoso. Quando preciso de algo específico escrevo uma query específica na mão e a vida segue. Estou muitoooo feliz com esta solução.
Assisti esse video quando lançou e é engraçado quando percebemos coisas diferentes de acordo com nossa experiência a primeira vez eu não tinha um mês de experiência e a única coisa que peguei do video era que o banco era caro e devia ser chamado o menor número de vezes possível mas não entendi muito bem o porquê de fazer a query na mão se o EF já fazia, a poucos dias depois de pegar um projeto, cabuloso de grande pra fazer, onde milhares de pessoas acessam entendi o motivo, no meu caso foi pra fazer uma tela de resumo das compras onde milhões de dados tem que ser tratado a tela demorava mais de 5 minutos pra carregar fazendo a query na mão ainda com EF só que com SqlRaw demora segundos isso é absurdo kkkkk programação realmente é prática quando tiver um curso que ensina na prática ele vai ser o curso perfeito
O que eu vejo muito hoje em dia é que os novos desenvolvedores têm muita indisposição para aprender a trabalhar com bancos relacionais nativamente, trabalhando queries das mais diversas com joins, collations, views, stored procedures, triggers, etc. Acontece que a performance da aplicação é muito dependente de como se trabalha na base de dados , conhecer sobre indexação, sobre que tipo de dado usar em cada coluna, sobre o custo no hd, sobre como o banco de dados trabalha os dados dentro da memória e sobre como ele faz as leituras dos dados é mais do que essencial, deveria ser a obrigação de todo desenvolvedor saber para desenvolver uma boa e performática aplicação. Minha opinião é que T-SQL deveria ser a primeira coisa que qualquer pessoa que esteja pensando a trabalhar em programação deveria dominar, a gente precisa entender bem a mexer com os dados antes mesmo de aprender a mexer com linguagens de programação. Parabéns pelo canal, caí de para-quedas aqui e curti bastante o vídeo! Já me inscrevi.
NHibernate permite isso. Usar o ORM e, para consultas mais complexas da pra usar Criteria com projections específicas ou em ultimo caso usar um hql ou mesmo native query.
São coisas que o NH faz desde sempre. Mas como explicar para quem usou o EF1 junto com aquela maluquice do edmx que agora é outro produto? Acho que tão cedo não voltamos pro EF. 🥲.@@baltaio
Aonde eu trabalho e principalmente no projeto que eu trabalho nós usamos uma salada de frutas literalmente(que está sendo removida agora com a migração para o .net6 e o refactory), bom em primeiro lugar existe um Micro Orm que foi construído pelo Arquiteto/Lider de Projeto da Empresa, ele é tão bom, tão bom que você precisa colocar as propriedades da classe na mesma ordem que está no banco de dados senão ele não faz o mappeamento e muito menos te avisa que o problema é essa, já tivemos mais de 10 horas de desenvolvimento mensal perdida por conta de ficar achando esses bugs... Depois teve um colega que precisou fazer um serviço de Data Stream para o ElasticSearch(pois segundo os meus colegas é um cache, enfim eu não vou nem discutir sobre), e aí ele usou dapper para fazer isso, porém as queries que eles criam não existe análise de performance ou nada do tipo simplismente eles fazem.... Eu na verdade gostaria muito de ter usado o dapper e suas extensões para fazer as queries porém a única coisa é que tem uma parte do sistema que usa bulkinsert, bulkupdate,bulkdelete e por aí vai, aonde que o dapper para usar isso ele precisa que pague e bomm como vocês devem imaginar pagar também não está nos planos... Foi então que eu cheguei que a conclusão mais óbvia é usar o RepoDb para fazer tudo isso, apesar de que eu tenho ainda algumas dores de cabeça com questões como multiplos constructors e resultset de functions ou procedures.... mas está atendendo até bem... Tem uma boa performance e você consegue fazer implementação de cache diretamente dentro dele, além de muitas outras coisas.... Então meu plano é que no final nós consigamos convencer a galera que cache é um redis... Mas enfim foi instrutivo o vídeo balta. PS: Pelo o que eu estive vendo o RepoDb ele é ainda mais performático que o Dapper em muitos cenários!!!
Boa noite Balta Parabéns pelo conteúdo Preciso de uma opinião sua vou iniciar um projeto (site para cadastrar produtores de café e seus produtos) Uso o dapper ou entity? Obrigado
@@Adams456 mesmo que vc saiba (listando e ordenando buscas no lugar certo, por ex), a performance é baixa comparado ao ADO e Micro ORMs, além do consumo de memória ser maior por mais que vc saiba usar muito bem o EF, ele perde numa busca simples (a não ser que apele para algum cache para isso - sacrificando mais memória)
Trabalhei em uma empresa que usava EF e possuía centenas de querys LINQ complexas, uma loucura só. Mal dava para entender as querys SQL geradas pelo framework. O sistema tinha uma performance tão ruim que começamos a usar ADO para as partes mais críticas.
Balta, você já mostrou como é o setup de desenvolvimento no Windows e no Linux, mostra como é no Mac OS! É seu principal sistema de trabalho em C#? Se sim, mostra de é possível trabalhar bem com uma linguagem da Microsoft no Mac Os
Exatamente. Seria interessante fazer um benchmark pra saber se as últimas versões do efcore estão com performance similar nas raws queries com o dapper.. vou fazer quando tiver um tempinho
Esse nosso mundo de TI é bem engraçado, lembro que quando EF era novidade eu ficava discutindo com minha equipe se realmente valia a pena aprender esse ORM ao invés de fazer as queries na mão, como de costume, mas me convenceram que não . Aí, hoje a discussão é se vale a pena fazer as queries na mão de novo kkkkk . Claro que isso é tirando os exageros e o ideal é mesmo analisar o seu cenário e fazer uma composição . O que é também extremamente recomendado e eu não vejo as equipes darem importância é em escrever queries performáticas utilizando os comando mais adequados sugeridos pela própria Microsoft e acredite, existem muitos . Enfim… obrigado pelos seus vídeos aprendo sempre muito . (Agora vou voltar na minha equipe de 7 anos atrás e falar “ihhh aeeeee, eu tinha razão!” Kkkkk Vlw flw🤙
Fala Balta, tô com um problema e você é minha última esperança 😁, eu não consigo executar o "dotnet tool install --global dotnet-ef", já tentei usar o VS Code, o Visual Studio 2022, simplesmente não executa, mostra uma sequências de erros, que não vale a pena copiar aqui, inclusive no Visual Studio cliquei em ajuda, para relatar um bug "diretamente" para a Microsoft, tentei inclusive diversas versões, o problema, é que como não instala não consigo gerar as migrações. Você já viu algo parecido? Tem alguma luz? Obrigado.
Em relação ao banco de dados salvar imagens, arquivos etc o ideal e nunca usar está opção visto que com poucos meses o banco vai está extremamente pesado, o ideal e usar cloud services, vale muito ORM devido aos tratamentos que ele já faz, se gasta menos tempo, em relação a sql complexos, você pode criar uma View e usar ela com o ORM sem problemas , basta usar o [NotMapped] isso vai evitar que o migration tente criar uma tabela, as consultas podemos usar por exemplo o FromSqlRaw
Ué, mas não seria só fazer migrations de query específicas (usando ef) como views não ? Com isso não resolveria o problema de ter controle sobre as querys mais específicas ?
@@baltaio Posso ter entendido errado. Mas pelo que entendi, um dos problemas do EF é que você não tem o controle total sobre como as querys estão sendo feitas. Assim para querys mais complexas, que cruzem informação e etc, poderia ser bom usar Dapper. Isso foi o que eu entendi. A pergunta é em cima disso. No caso, se eu desejo ter controle sobre alguma query mais complexa, bastaria eu criar ela como view, usando o EF. Isso não resolveria o problema ? Caso eu tenha entendido algo errado, pode dizer também .
Utilizo o EF para tudo. Tenho poucos projetos utilizando Dapper porém, sou muito produtivo em utilizar o EF. O EF acompanha paralelamente as atualizações do .NET. Me parece que o Dapper não tem recebido atualizações deste novembro de 2021.
Depende muito do projeto. Acredito que a questão de performance não é culpa do framework X ou Y mas mais da forma que as classes e bancos de dados foram arquitetados, da forma como o sistema deve carregar as informações. Classes Guerreiras com mais de 60 propriedades, dezenas e dezenas de objetos aninhados... Mandar isso para o EF e esperar performance é inviável, até mesmo no Dapper. As classes devem ser pequenas, objetos devem ser pequenos. Para sistemas novos é seguir essa regra a risca sempre que possível. Para sistemas legados a conversa muda.
EF é maravilhoso mas o problema é que ele é limitado existe consultas mais complexas que ele não acaba não suportando, nessas horas corremos para as Consultas SQL
Salve mestre Balta. Eu tenho tentado usar o EF Core sempre que possível e neste caso onde há necessidade de muitos joins/includes segui a doc da microsoft que aconselha dividir em mais de uma query, o que nos meus casos até agora resolveu o problema de perfomance. Existe alguma biblioteca de benchmark que faça comparação de ações no banco?
Utilizo EF pra tudo com Odata na ponta do serviço, nossa me agiliza muito tempo. Query complexa boto em view e deixo por conta do banco de dados, soco memória no banco. Banco Microsoft sql server, já testei com my sql e postgre, mas aí perde bastante performance mesmo
Trabalhei 35 anos num banco. 95% do meu trabalho foram sempre consultas para estatisticas e afins. 5% inserts, updates.... portanto saber SQL é fundamental. Jâ para não falar em outras consultas sobre datalakes. NOSQL..
Eu gosto bastante do Dapper, pois nem sempre eu quero buscar todas as informações do banco de dados, e naturalmente nós tornamos desenvolvedores mais conscientes pois você vai ter mais contato com o banco de dados. Eu acredito que esse discurso de tirar a responsabilidade de escalonamento de determinados serviços da mão do desenvolvedor é meio prejudicial pensando em Engenharia de Software. Minha opinião, muito interessante o vídeo.
Usei EF em alguns projetos, mais nao gostei, a gente perde o controle sobre o sql gerado, gera coisas desnecessarias, para mim a unica coisa que uso e que ele faz muito bem e a questao de criacao do banco de dados, mais dentro do projeto, para insert, update, select, muito complicado. ainda mais que qualquer coisa que vai fazer precisa estar compilando o projeto.
Nossa. Eu uso .Net numa vps hostinger, não preciso me preocupar nem um pouco em economizar banco. Banco de dados como serviço tô fora. Prefiro meter o MySQL numa vps e ser feliz.
Vcs fazem 50 mil linhas de codigos,.. talvez uma querie não deve ser tao complicado assim ,.. as vezes essas ferramentas de caixotes... lançam cada querie monstrosas para o Banco de Dados... q certamente performaria melhor se tivesse sido feita por humano ... e direto no que se quer obter do banco de dados, mas entendo uma facilidade no dia a dia do programador... mas se é mehor... ou nao ... é questao de analisar bem cada situacao
Calma, foi só um exemplo hahahaha A moral do vídeo é que ambos tem coisas boas e ruins... Por exemplo, pra usar o ExecuteRawQuery eu preciso de um DbSet de um objeto (Relacionado a View, Query ou Proc) e consequentemente de um DbContext. No Dapper eu consigo fazer essa query direto e mapear para um dynamic se precisar. Inclusive é uma das (poucas e únicas) vantagens do Dapper na minha opinião :) Mas obrigado pelo comentário!
Não sei se o Marcos do Palmeiras imita o Balta,ou vice versa.kkk ORM é uma merda,só serve para OS CRUDS da vida,São Tomé nunca usaria ORM..Mas para quem ama ORM,pelo menos tem que tentar entender de modelagem de dados,uma modelagem porca ,invariavelmente vai acabar em uma metralhadora de SQL.Experiência do usuário,runtime e conta da Cloud,vão ser sempre mais importantes que mordomia para programador.Só perde para um ORM em performance quem não sabe SQL,simples assim,quem sabe com IA daqui uns 20 anos isso aconteça.
Nunca usei o dapper, mas com certeza o EntityFramework é ruim. Aliás acho o C# no geral ruim. eu trocarei EF e o C# por quarkus com hibernate ou nest.js com TypeORM em qualquer oportunidade que eu puder, acho a documentação da microsoft fraca mesmo em inglês e tenho dificuldades de encontrar blogs e posts do assunto e mesmo o stack overflow sempre tem pouco conteudo ou respostas pobres, mas de fato o linq é uma coisa ótima que facilida muito a vida da hora de desenvolver.
Já uns bons anos atrás eu tinha abandonado o EF por completo usava apenas Dapper. Mas daí eu precisei desenvolver um sistema novo, e precisava de velocidade e aos poucos eu fui retornando ao EF. E hoje eu estou nessa que vc comentou no vídeo. Eu uso o máximo que dá pra usar em EF, e as coisas críticas eu faço na mão com Dapper. Esse me mostrou ser o melhor cenário.
💜
Realmente eu também tenho a mesma visão, uso o EF telas simples, quando preciso de uma tela que tem que fazer umas consultas mais elaboradas, como 2 ou 3 joins aí já prefiro partir pra views escrita na mão.
Tive um projeto onde os dados eram muito grandes em casa base, cerllca de 700 mil registros nas bases maiores, pra esse projetos fizemos pre processemto dos dados e gerando views pra tela consumir o mais mastigado possível, ficou super rápido a parte de tela.
Realmente esse é o melhor caminho hj.
🚀
Eu como DBA te digo que parte de alguns problemas de performance em algumas aplicações é por conta de ad-hoc executado via ORM. O que chove de queries com parâmetro NVARCHAR é surreal, isso mata o uso dos índices (no SQL Server, no caso), entre outros problemas de performance. Eu como DBA não odeio a ORM, só acho que as configurações de parâmetros e as escolhas das colunas adequadas para o método e afins devem ser feitas com muito cuidado.
Legal demais esse ponto de vista... realmente tem que inspecionar bem, principalmente o código pra gerar o banco nas migrations... me dá agonia as vezes hahahha..
PS:. Dá pra configurar tudo pelo EF, bonitinho, certinho...
Grande Balta.. a lenda do c#
🚀🚀🚀🚀
Esses dias tive de desenvolver um sistema com Windows Forms no trampo, e na hora de escolha do acesso a dados, levei em conta justamente o que aprendi nos seus cursos, Balta. No final, ficava melhor usar as queries manuais com Dapper, pelo fato de que era justamente isso, muitos dados cruzados. Na hora que pensei nisso usando EF, deu logo um calafrio e resolvi fazer a escolha correta. Valeuzão pelo aprendizado!!
💜
Top essa JPM aí no fundo
Tem mais uma de 7 cordas... JP7 💜
Estou usando o EF com o Dapper no meu trabalho atual.
EF pra inclusão e atualização dos dados e para consultas mais simples e Dapper pra consultas mais complexas.
Esse foi a solução que os arquitetos de software do time acharam para melhorar o desempenho da aplicação.
E em algumas consultas a diferença do uso do Dapper pro EF foi gritante.
Justamente porque era mais simples fazê-las em SQL diretamente do que fazê-las no EF.
Eu particularmente prefiro fazer as consultas "na mão", mas cada caso é um caso.
💜
e da para fazer consultas mais simples estilo EF com o Dapper contrib
@@ramonarthur2729 Sim. Essa abordagem parece interessante quando não se tem o EF e não se quer usá-lo.
Boa balta. Aqui, dependendo da aplicação, usamos os dois. O EF para operações de gravação (insert, delete e update). O EF tem uma grande vantagem sobre o dapper que é o gerenciamento de estado. Isso eh útil particularmente ao persistir agregados. Já o dapper faz o que ele faz de melhor que é ler as informações de forma performática e com maior controle sobre as querys.
💜💜
Top isso aí, bom senso no uso das tecnologias nos cenários adequados,
o grande problema é quando chega um sênior com 50 anos de experiência e coloca uma lei pra usar só Dapper, ADO puro, Store Procedures pra tudo,
a conclusão que eu tenho é que essas pessoas estão é procurando o conforto porque não evoluíram, mas condenam um projeto a uma extrema complexidade de manutenção
Tudo depende do tipo de projeto, para aplicações bancárias por exemplo vejo que é usado muito as stored procedures, acredito que seja para dar um nível de segurança ainda maior ao código.
O segredo é ponderar! 💜
Comecei usando o EF recentemente, ainda estou aprendendo e consumindo conteúdo sobre. Em breve verei o dapper.
🚀
Adoro dapper. Amor a primeira vista 😍
💜💜
Eu uso Eloquent com Laravel e Hibernete com Java, faço exatamente isso, não uso um ORM em 100% do sistema. Em relatórios por exemplo preciso cruzar diversas informações então trabalho com SQL diretamente, em consultas simples eu uso o ORM, faço da forma como foi explicado ai, dá pra trabalhar com 100% usando SQL direto mas não dá pra trabalhar 100% com ORM porém o ORM facilita bastante em alguns tipos de implementação.
🚀
Eu uso os dois EF e Dapper, tenho sistema inteiro usando EF e outros só usando Dapper, gosto de usar o Dapper quando pego sistemas legados onde a base não está tão bem estruturada.
💜
Uso o EF com migrations no automatic. Amooooooo. É maravilhoso. Quando preciso de algo específico escrevo uma query específica na mão e a vida segue. Estou muitoooo feliz com esta solução.
Prático né, Moshe? 💜
Assisti esse video quando lançou e é engraçado quando percebemos coisas diferentes de acordo com nossa experiência a primeira vez eu não tinha um mês de experiência e a única coisa que peguei do video era que o banco era caro e devia ser chamado o menor número de vezes possível mas não entendi muito bem o porquê de fazer a query na mão se o EF já fazia, a poucos dias depois de pegar um projeto, cabuloso de grande pra fazer, onde milhares de pessoas acessam entendi o motivo, no meu caso foi pra fazer uma tela de resumo das compras onde milhões de dados tem que ser tratado a tela demorava mais de 5 minutos pra carregar fazendo a query na mão ainda com EF só que com SqlRaw demora segundos isso é absurdo kkkkk programação realmente é prática quando tiver um curso que ensina na prática ele vai ser o curso perfeito
🚀🚀
Eu to fazendo um soft só com entity e depois vou fazer uma com dapper. Pra eu conseguir montar uma opniao. Mas bom saber que tem q ponderar.
Isso aí!!! 💜
O que eu vejo muito hoje em dia é que os novos desenvolvedores têm muita indisposição para aprender a trabalhar com bancos relacionais nativamente, trabalhando queries das mais diversas com joins, collations, views, stored procedures, triggers, etc.
Acontece que a performance da aplicação é muito dependente de como se trabalha na base de dados , conhecer sobre indexação, sobre que tipo de dado usar em cada coluna, sobre o custo no hd, sobre como o banco de dados trabalha os dados dentro da memória e sobre como ele faz as leituras dos dados é mais do que essencial, deveria ser a obrigação de todo desenvolvedor saber para desenvolver uma boa e performática aplicação.
Minha opinião é que T-SQL deveria ser a primeira coisa que qualquer pessoa que esteja pensando a trabalhar em programação deveria dominar, a gente precisa entender bem a mexer com os dados antes mesmo de aprender a mexer com linguagens de programação.
Parabéns pelo canal, caí de para-quedas aqui e curti bastante o vídeo! Já me inscrevi.
💜
Balta, realmente me interessa saber como você utiliza a infraestrutura da Azure. Seu conteúdo é muito bom!
Legal né... vou fazer um vídeo comentando! 💜
Balta, vc é top!
💜💜💜💜💜
NHibernate permite isso. Usar o ORM e, para consultas mais complexas da pra usar Criteria com projections específicas ou em ultimo caso usar um hql ou mesmo native query.
EF permite isso também... na versão 8 permite isso pra unmapped types também!
São coisas que o NH faz desde sempre. Mas como explicar para quem usou o EF1 junto com aquela maluquice do edmx que agora é outro produto? Acho que tão cedo não voltamos pro EF. 🥲.@@baltaio
Ótimo vídeo
Obrigado💜💜💜💜
Dapper é muito prático. Tenho utilizado bastante em substituição ao ADO.
💜
Perfeito. COMO SEMPRE. Balta fale algo neste nível ai sobre transações.
💜💜💜💜
Olha os ex delpheiros kkk
@@jonatanfelipe9315 huahuhuahuahuauh
🔴 MASTERCLASS GRATUITA - EF VS DAPPER
👉go.balta.io/masterclass-dapper-vs-entity-framework?TH-cam&
Aonde eu trabalho e principalmente no projeto que eu trabalho nós usamos uma salada de frutas literalmente(que está sendo removida agora com a migração para o .net6 e o refactory), bom em primeiro lugar existe um Micro Orm que foi construído pelo Arquiteto/Lider de Projeto da Empresa, ele é tão bom, tão bom que você precisa colocar as propriedades da classe na mesma ordem que está no banco de dados senão ele não faz o mappeamento e muito menos te avisa que o problema é essa, já tivemos mais de 10 horas de desenvolvimento mensal perdida por conta de ficar achando esses bugs... Depois teve um colega que precisou fazer um serviço de Data Stream para o ElasticSearch(pois segundo os meus colegas é um cache, enfim eu não vou nem discutir sobre), e aí ele usou dapper para fazer isso, porém as queries que eles criam não existe análise de performance ou nada do tipo simplismente eles fazem.... Eu na verdade gostaria muito de ter usado o dapper e suas extensões para fazer as queries porém a única coisa é que tem uma parte do sistema que usa bulkinsert, bulkupdate,bulkdelete e por aí vai, aonde que o dapper para usar isso ele precisa que pague e bomm como vocês devem imaginar pagar também não está nos planos... Foi então que eu cheguei que a conclusão mais óbvia é usar o RepoDb para fazer tudo isso, apesar de que eu tenho ainda algumas dores de cabeça com questões como multiplos constructors e resultset de functions ou procedures.... mas está atendendo até bem... Tem uma boa performance e você consegue fazer implementação de cache diretamente dentro dele, além de muitas outras coisas.... Então meu plano é que no final nós consigamos convencer a galera que cache é um redis... Mas enfim foi instrutivo o vídeo balta. PS: Pelo o que eu estive vendo o RepoDb ele é ainda mais performático que o Dapper em muitos cenários!!!
No EF 7 tem BulkUpdate :)
Muito obrigado pelo conteúdo! Já compartilhei com meus colegas do serviço! Sucesso!
💜
Boa noite Balta
Parabéns pelo conteúdo
Preciso de uma opinião sua vou iniciar um projeto (site para cadastrar produtores de café e seus produtos)
Uso o dapper ou entity?
Obrigado
Não tenho como te responder sem ter uma base do cenários, números... Minha dica é fazer uma POC e ver qual melhor te atende!
Ainda não tive oportunidade de usar o Dapper, mas utilizou o Entity e estou bem satisfeito com sua performance
💜💜💜
mas ele é bem lento, vai sentir caso esteja em projetos que envolva alta concorrência
@@pgnt não é não, tem que saber o que está fazendo
@@Adams456 mesmo que vc saiba (listando e ordenando buscas no lugar certo, por ex), a performance é baixa comparado ao ADO e Micro ORMs, além do consumo de memória ser maior
por mais que vc saiba usar muito bem o EF, ele perde numa busca simples (a não ser que apele para algum cache para isso - sacrificando mais memória)
Concordo.
💜
Eu uso os dois, para queries mais complexas e muitos relacionamentos, acho o Dapper mais perfomático.
💜
Trabalhei em uma empresa que usava EF e possuía centenas de querys LINQ complexas, uma loucura só. Mal dava para entender as querys SQL geradas pelo framework. O sistema tinha uma performance tão ruim que começamos a usar ADO para as partes mais críticas.
💜
Mesmo problema que acontece onde trabalho, mas lá usamos NHibernnate.
Balta, você já mostrou como é o setup de desenvolvimento no Windows e no Linux, mostra como é no Mac OS! É seu principal sistema de trabalho em C#? Se sim, mostra de é possível trabalhar bem com uma linguagem da Microsoft no Mac Os
Boaaaa 💜
Mesclar os dois e obter o melhor de ambos.
💜
Salve Balta, trás pra gente mais sobre a infra do site e as estratégias utilizadas sim, seria um conteúdo bem interessante
Boaaaa!! Sempre comento sobre isso nos Encontros Premium!
Por que usar Dapper se dá para usar SQL em no EF quando for necessário otimizar?
Exatamente. Seria interessante fazer um benchmark pra saber se as últimas versões do efcore estão com performance similar nas raws queries com o dapper.. vou fazer quando tiver um tempinho
Por que usar EF se dá pra usar Dapper.Contrib? Existem os dois lados da história... vou falar sobre isto no evento do dia 26!!
top
💜
tinham que conhecer o repodb, ORM que é praticamente a união da forma do Dapper e EF juntos
Obrigado pela dica 💜
Esse nosso mundo de TI é bem engraçado, lembro que quando EF era novidade eu ficava discutindo com minha equipe se realmente valia a pena aprender esse ORM ao invés de fazer as queries na mão, como de costume, mas me convenceram que não
.
Aí, hoje a discussão é se vale a pena fazer as queries na mão de novo kkkkk
.
Claro que isso é tirando os exageros e o ideal é mesmo analisar o seu cenário e fazer uma composição
.
O que é também extremamente recomendado e eu não vejo as equipes darem importância é em escrever queries performáticas utilizando os comando mais adequados sugeridos pela própria Microsoft e acredite, existem muitos
.
Enfim… obrigado pelos seus vídeos aprendo sempre muito
.
(Agora vou voltar na minha equipe de 7 anos atrás e falar “ihhh aeeeee, eu tinha razão!” Kkkkk
Vlw flw🤙
Acredito que é uma discussão válida e que ainda vai se estender. No fim não tem certo ou errado, depende do projeto!
Só faz na mão algo muito complexo que não performa bem no entity, o resto cara, tudo no entity
Fala Balta, tô com um problema e você é minha última esperança 😁, eu não consigo executar o "dotnet tool install --global dotnet-ef", já tentei usar o VS Code, o Visual Studio 2022, simplesmente não executa, mostra uma sequências de erros, que não vale a pena copiar aqui, inclusive no Visual Studio cliquei em ajuda, para relatar um bug "diretamente" para a Microsoft, tentei inclusive diversas versões, o problema, é que como não instala não consigo gerar as migrações. Você já viu algo parecido? Tem alguma luz? Obrigado.
Eita, usa nosso fórum, é melhor -> github.com/balta-io/forum/discussions
Valeu!! 💪🏼
Em relação ao banco de dados salvar imagens, arquivos etc o ideal e nunca usar está opção visto que com poucos meses o banco vai está extremamente pesado, o ideal e usar cloud services, vale muito ORM devido aos tratamentos que ele já faz, se gasta menos tempo, em relação a sql complexos, você pode criar uma View e usar ela com o ORM sem problemas , basta usar o [NotMapped] isso vai evitar que o migration tente criar uma tabela, as consultas podemos usar por exemplo o FromSqlRaw
💜
Ué, mas não seria só fazer migrations de query específicas (usando ef) como views não ?
Com isso não resolveria o problema de ter controle sobre as querys mais específicas ?
Não entendi muito bem sobre qual ponto está falando...
@@baltaio Posso ter entendido errado. Mas pelo que entendi, um dos problemas do EF é que você não tem o controle total sobre como as querys estão sendo feitas. Assim para querys mais complexas, que cruzem informação e etc, poderia ser bom usar Dapper.
Isso foi o que eu entendi. A pergunta é em cima disso.
No caso, se eu desejo ter controle sobre alguma query mais complexa, bastaria eu criar ela como view, usando o EF. Isso não resolveria o problema ?
Caso eu tenha entendido algo errado, pode dizer também .
Utilizo o EF para tudo. Tenho poucos projetos utilizando Dapper porém, sou muito produtivo em utilizar o EF. O EF acompanha paralelamente as atualizações do .NET. Me parece que o Dapper não tem recebido atualizações deste novembro de 2021.
💜💜
Depende muito do projeto. Acredito que a questão de performance não é culpa do framework X ou Y mas mais da forma que as classes e bancos de dados foram arquitetados, da forma como o sistema deve carregar as informações.
Classes Guerreiras com mais de 60 propriedades, dezenas e dezenas de objetos aninhados... Mandar isso para o EF e esperar performance é inviável, até mesmo no Dapper.
As classes devem ser pequenas, objetos devem ser pequenos.
Para sistemas novos é seguir essa regra a risca sempre que possível.
Para sistemas legados a conversa muda.
💜
O pessoa também usa muito o nhibernante.
Muito bom também!!! 💜
EF é maravilhoso mas o problema é que ele é limitado existe consultas mais complexas que ele não acaba não suportando, nessas horas corremos para as Consultas SQL
🚀
André, Mas posso usar os dois no mesmo projeto ?
Opa, pode sim!
Salve mestre Balta.
Eu tenho tentado usar o EF Core sempre que possível e neste caso onde há necessidade de muitos joins/includes segui a doc da microsoft que aconselha dividir em mais de uma query, o que nos meus casos até agora resolveu o problema de perfomance.
Existe alguma biblioteca de benchmark que faça comparação de ações no banco?
Existe sim... chama Benchmark!! 💜
Utilizo EF pra tudo com Odata na ponta do serviço, nossa me agiliza muito tempo.
Query complexa boto em view e deixo por conta do banco de dados, soco memória no banco. Banco Microsoft sql server, já testei com my sql e postgre, mas aí perde bastante performance mesmo
Obrigado pelo comentário! 💜
Algum material bom para implementar dapper com sql e orm no net 7 no mesmo projeto?
Opa, nosso curso de Dapper 💜
@@baltaio qual o curso?
Trabalhei 35 anos num banco. 95% do meu trabalho foram sempre consultas para estatisticas e afins. 5% inserts, updates.... portanto saber SQL é fundamental. Jâ para não falar em outras consultas sobre datalakes. NOSQL..
Obrigado pelos dados 💜
Prefiro fazer na mão, comentando antes de assistir kkkk
💜
Depois de vê um teste de carga batendo em sua api…Td muda
hahahaha, como dizia meu amigo Mike Tyson: "Todo mundo tem um plano até tomar um soco na cara"
e no TikTok ??
@balta.io 💜
na empresa que usamos Nhibernate e Dapper, prefiro mil vezes usar o Dapper.
💜💜💜
Eu gosto bastante do Dapper, pois nem sempre eu quero buscar todas as informações do banco de dados, e naturalmente nós tornamos desenvolvedores mais conscientes pois você vai ter mais contato com o banco de dados. Eu acredito que esse discurso de tirar a responsabilidade de escalonamento de determinados serviços da mão do desenvolvedor é meio prejudicial pensando em Engenharia de Software. Minha opinião, muito interessante o vídeo.
Obrigado pelo comentário!
Usei EF em alguns projetos, mais nao gostei, a gente perde o controle sobre o sql gerado, gera coisas desnecessarias, para mim a unica coisa que uso e que ele faz muito bem e a questao de criacao do banco de dados, mais dentro do projeto, para insert, update, select, muito complicado. ainda mais que qualquer coisa que vai fazer precisa estar compilando o projeto.
Eita!
Nossa. Eu uso .Net numa vps hostinger, não preciso me preocupar nem um pouco em economizar banco. Banco de dados como serviço tô fora. Prefiro meter o MySQL numa vps e ser feliz.
🚀
Uso o EF com views.
É uma boa hein!! 💜
Vcs fazem 50 mil linhas de codigos,.. talvez uma querie não deve ser tao complicado assim ,.. as vezes essas ferramentas de caixotes... lançam cada querie monstrosas para o Banco de Dados... q certamente performaria melhor se tivesse sido feita por humano ... e direto no que se quer obter do banco de dados, mas entendo uma facilidade no dia a dia do programador... mas se é mehor... ou nao ... é questao de analisar bem cada situacao
💜
Eu uso EF. Para queries complexas o melhor na minha opiniao é usar views chamadas pelo EF. Dapper eu nao conheço portanto nao vou opinar.
💜
Utilizo dessa forma também.
No EF você pode mapear a partir de uma consulta escrita na mão. Não precisa necessariamente usar Linq. Que drama. Se atualiza.
Calma, foi só um exemplo hahahaha
A moral do vídeo é que ambos tem coisas boas e ruins...
Por exemplo, pra usar o ExecuteRawQuery eu preciso de um DbSet de um objeto (Relacionado a View, Query ou Proc) e consequentemente de um DbContext.
No Dapper eu consigo fazer essa query direto e mapear para um dynamic se precisar.
Inclusive é uma das (poucas e únicas) vantagens do Dapper na minha opinião :)
Mas obrigado pelo comentário!
Não sei se o Marcos do Palmeiras imita o Balta,ou vice versa.kkk ORM é uma merda,só serve para OS CRUDS da vida,São Tomé nunca usaria ORM..Mas para quem ama ORM,pelo menos tem que tentar entender de modelagem de dados,uma modelagem porca ,invariavelmente vai acabar em uma metralhadora de SQL.Experiência do usuário,runtime e conta da Cloud,vão ser sempre mais importantes que mordomia para programador.Só perde para um ORM em performance quem não sabe SQL,simples assim,quem sabe com IA daqui uns 20 anos isso aconteça.
É uma opinião bem forte 🤣
PS:. O marcos que me imita hahahhaah
Nunca usei o dapper, mas com certeza o EntityFramework é ruim. Aliás acho o C# no geral ruim. eu trocarei EF e o C# por quarkus com hibernate ou nest.js com TypeORM em qualquer oportunidade que eu puder, acho a documentação da microsoft fraca mesmo em inglês e tenho dificuldades de encontrar blogs e posts do assunto e mesmo o stack overflow sempre tem pouco conteudo ou respostas pobres, mas de fato o linq é uma coisa ótima que facilida muito a vida da hora de desenvolver.
É ruim mesmo? Certeza? Dá uma conferida no nosso curso de EF!! Tenho certeza que vai se surpreender! 💜
Eu acho que o problema é você