ORM vs SQL puro

[@rotognin]

100sacional. Dois feras conversando, eu só aprendo! Valeu!

[@brunodurao614]

Reiniciando a máquina para ver se a query funciona no ORM. Kkkkkkk Genial!!!

[@Leanst.]

O relato do Branas foi mais ou menos a minha experiência com NH e HQL kkkkkk Porém Chegou num ponto da coisa que a complexidade aumentou tanto que era mais fácil jogar tudo fora e começar do zero do que dar manutenção naquela macarronada toda. Para se fazer as coisas era complexo e não sabíamos direito se o caminho adotado era mesmo aquele, pois parecia trabalhoso d+ criar coisas com HQL sendo que com SQL seria resolvido mais simplesmente e com menos complexidade.

[@iscux]

Só o fato da pergunta do título do vídeo ser algo que está em alta hoje em dia já mostra o quão imaturo os ORMs dos ecosistemas considerados "modernos" são.

[@nivel7tecnologia]

Parabéns pela live. Um tema muito interessante e que vale muito apena ser abordado.

[@baltaio]

🚀🚀

[@phjb7]

Assistir pela twitch, mas tive que passar aqui só pra deixar meu like! Muito bom conteúdo. Obrigado por trocarem o almoço para semear conhecimento!

[@baltaio]

🚀🚀🚀

[@rockleo78]

Eu usava muito ORM, Até conhecer o micro ORM dapper e para mim é a melhor forma de se trabalhar, mas acho q isso é bem pessoal, e vai muito da experiência de cada um com SQL...

[@carlosfonteles8464]

Passei pelo mesmo dilema. Utilizo o EF num projeto, mas depois que deu uns problemas de performance, estou começando a migrar pro Dapper. Pelo que pude perceber até agora, no balanço dos prós e contras, o Dapper é melhor.

[@elan2199]

@@carlosfonteles8464 Eu pessoalmente gosto muito do EF, mais pela praticidade mesmo. Mas realmente vejo um certo gargalo durante a montagem de queries muito grandes

[@marcoscarvalho9956]

Balta meu guru da TI valeu....

[@ricardocardoso3314]

Excelente debate. Por eu ter bastante conhecimento em SQL, já ocorreu algumas vezes na empresa a necessidade de realizar apoio a algum desenvolvedor trabalhando com ORM, devido a performance da execução das queries geradas por ele.

[@baltaio]

🚀🚀

[@brunodurao614]

Maravilhoso debate. Assinando o canal. Obrigado.

[@estudandocomoroger]

Foi top demais essa live!

[@baltaio]

🚀

[@druzo1]

Trigger é algo que tem que ser usado com muita sabedoria, já tive problemas complicados por conta do recurso.

[@baltaio]

Com certeza

[@matheuscampaninimughrabi5933]

Sensacional a discussão

[@leonardoluz3713]

Teu site ta sem data nos posts... como vou saber quando vc diz: "ainda", de quando estamos falando?. Desde já obrigado pelo conteudo.

[@baltaio]

💜

[@willianpereiradossantos2258]

Usar ORM quando couber, quando isso te facilitar a vida. E usar SQL puro quando isso couber, quando o ORM nao atender ou tornar a tarefa mais complexa do que usar SQL puro.

[@baltaio]

Isso ai

[@pedrooctavio5817]

Muito boa esse papo! Uma dúvida, nos meus projetos que contém Commanda e Queries com Dapper, eu parei de usar entidades, isso é correto? Não estou vendo sentido em usar entidades nesse caso.

[@emerson51802]

Eu prefiro trabalhar com SQL puro, isso por que gosto muito de escrever as minhas querys

[@baltaio]

💜

[@fsilva1985]

As vezes a orm gasta muita memória para fazer algumas querys que acabo usando raw.

[@baltaio]

🚀

[@evertontomazi]

Tem algo sobre xunit?

[@baltaio]

Temos sobre MSTests, a base!! Depois o framework você varia! 💜

[@aldycolares3663]

Pode postar nos comentários o link do Twitter da discussão 2:13

Tudo que é muito conveniente acaba sendo ineficiente a longo prazo.

[@AlienCodador]

2 Grandes!

[@AlienCodador]

Eu vou do ponto nessa questão assim, tenho uma empresa de software pequena, 4 desenvolvedores, então entregamos o software com ORM, e depois nas query que vemos se alguma query der um gargalo, nós transformamos ela em em SQL puro, isso já ajuda bastante.

[@brunodurao614]

ORM -> Object Relational Mismatch Palavras de Uncle Bob.

[@ronaldodev]

eu prefiro escrever o SQL puro nativo, ORM é para casos mais simples

[@baltaio]

💜💜

[@rogeriorlima3]

ORM = Tecnologia horrível! - uma modinha que infelizmente o mercado ingenuamente abraçou. Gera grandes problemas no longo prazo e deixa a manutenção mais difícil. Os DBAs detestam e com razão. Agora só aqui entre nós... deixar que uma camada de software escrita por terceiros, fazer operações no banco de dados da empresa é ser muito, mas muito ingênuo ne ? ... e para convencer a adoção usam o ótimo argumento: Produtividade. Galera, façam um favor para VCS próprios: Parem de usar ORM e escrevam os sql statements. Abs :) (vídeo legal gostei)

[@paulomfgoncalves]

Concordo em absoluto !!!! Haja gente inteligente !!! e sobre a questão da produtividade; custa assim tanto fazer uma classe com mapeamentos? 95% das situações são consultas a BD. Relatorios e pesquisas complexas.