Excelente visão! Também já tive alguns problemas com AutoMapper em objetos complexos. mas não tinha parado pra analisar os detalhes e ver que não vale a pena.
Cara, obrigado pela aula de AutoMapper kkk os pontos abordados vai me ajudar a ganhar bastante tempo em alguns CRUDS de uma aplicação. No meu ponto de vista, os Mappers tem os locais onde pode ser usados, não é uma regra pra toda aplicação. Nos locais que vai ajudar a ganhar tempo, entendo que pode ser utilizado tranquilamente, em outros locais que mais vai gerar perda de tempo tentando descobrir como faz, vai lá e faz nativo e boa! Valeu!
Concordo contigo, eu era fã do AutoMapper, mas percebi que alguns projetos não estavam mais usando, agora vejo que realmente não é tão vantajoso e não uso mais no meus projetos.
Opa, concordo com seu ponto vista não vejo problema em usar o automapper porém se o projeto exige performance eu prefiro não usar porém deixa em aberto para os devs criar os mappers manualmente e acabam criando regras além de mapeamento. Em resumo automapper não são performaticos porém dificulta alguém de adicionar uma regra de negócio no mapeamento e mapear manualmente tem o ganho de performance porém abre margem para adicionar regras de negócio. Muito bom o conteúdo parabéns 👏🏻
Obrigado por acrescentar sua experiencia mano! Sim, mappers podem ser uteis e tem sua sim proposta, a ideia foi mais explicar o porque de eu achar que as vezes cria um problema ao inves de solução
Achei interessante o conteúdo abordado, e confesso que nunca vi dessa perspectiva porque nunca levei em consideração atualizar um objeto existente com automapper, eu realizo sempre a criação do objeto por ele as vezes, e quando preciso atualizar os dados eu faço isso por métodos na classe, eu acredito que dessa forma fica mais claro as responsabilidades de cada classe. O problema do comparador de igualdade para collections também nunca passei por ele pela forma que sempre trabalho, mas é bom conhecer que esse problema existe e tem solução. Minha posição é similar a sua, para projetos pequenos não vejo relevância no uso do automapper, mas para os projetos maiores na minha visão faz sentido por conta da repetição de código e por configurar isso uma só vez, apesar dos problemas em runtime que podem aparecer e só são pegos por teste de integração. A dificuldade maior está em compreender alguns imprevistos no uso pela forma que a ferramenta funciona, pelo debug que não é tão simples as vezes exigindo vários breakpoints nos construtores, e pela flexibilidade durante o mapeamento que quando feito por método estático é bem maior na minha opinião. É tudo uma questão de tamanho do projeto para mim. Essa é só minha opinião. Excelente vídeo
Duas perguntas aqui, pq não passar no construtor da entidade o DTO inteiro e tratar a conversão dentro dele como "new Pessoa( pessoaDTO )"? E recentemente eu li um artigo sugerindo usar Implicit Operator pra tratar as conversões, o que vc acha disso?
Essa é uma alternativa também mano! Não vejo problema de fazer para DTO para Entidade. Implicit operator eu gosto de usar nesses casos também, faz sentido, mas nesse caso a declaracao, fica melhor sem var, tipo, Pessoa pessoa = pessoaDtoObj... Faz sentido também lenda!
Cara, eu não sei deixei transparecer isso, mas eu não uso UOW no lugar de repository, eu acredito que um acrescenta ao outro, eu usaria ambos juntos, a unica ideia que eu tenho hoje, é que na maioria das vezes eu não implemento repository pois isso meio que tira o poder do EF, e outra, o EF já implementa repository, é como fazer uma abstração da abstração... Isso é papo para outro video sauhshauhuas Tmjj meu irmão!
Na minha experiência, mappers dão muitos problemas e quando tu tem que configurar um de alguma forma muito especifica da muito mais dor de cabeça do que fazer na mão haha. Bom vídeo abrcs.
Cara, a treta é que maioria dos projetos já tem o AutoMapper rodando, aí vc acaba caindo nesses cenários de ter que criar inúmeras regras dentro das configs dele. Sobre o que vc comentou no final, fiquei em dúvida, pq vc não curte muito o padrão repository?
Cara, isso é papo para outro café, na verdade eu não consigo ver valor no padrão repository quando é usado com Entity Framework, eu vejo que a gente perde poder do Entity fazendo isso.
Opa, legal sua visão e concordo com vc, veja bem, seu contexto é um modelo simples. Agora o projeto tem um objeto que tem vários itens e cada itens tem um subitem. Exemplo: Despesa -- ItensDespesa----Pagamentos, somente um DTO para o front demonstrar... AutoMapper vai ajudar e muitooo, nao concorda ? Por favor exemplifique isso pra gente seria um ganho gigantesco no meu conhecimento.
Sim e não ao mesmo tempo, pq eu imagino o tanto de config que deve ser criado para ele entender essas relações, ainda sim, não vejo valor no AutoMapper, pois se ocorrer um erro de mapeamento vai ter que estudar mais ainda a ferramenta para configurar, acho besteira... Dependendo da configuração também, ele não irá trazer somente os campos a serem mapeados, iria provavelmetne trazer todos os campos e após isso fazer o mapeamento, o que não vale muito a pena também
Excelente visão! Também já tive alguns problemas com AutoMapper em objetos complexos. mas não tinha parado pra analisar os detalhes e ver que não vale a pena.
Boaaa mano! Agora da próxima você vai pensar duas vezes antes de usar 😅😅
Top mano, muito interessante o conteúdo abordado!! Parabéns pelo ótimo conteúdo
Tmj meu querido! Vlwww
Boa! Concordo de mais! Eles geram uma carga cognitiva grande quando você ta dando manutenção, porque as regras e configurações estão por espalhadas.
Sim, maior trampo ali pra configurar uma concatenação de strings 🫠
Cara, obrigado pela aula de AutoMapper kkk os pontos abordados vai me ajudar a ganhar bastante tempo em alguns CRUDS de uma aplicação.
No meu ponto de vista, os Mappers tem os locais onde pode ser usados, não é uma regra pra toda aplicação. Nos locais que vai ajudar a ganhar tempo, entendo que pode ser utilizado tranquilamente, em outros locais que mais vai gerar perda de tempo tentando descobrir como faz, vai lá e faz nativo e boa!
Valeu!
UHShuashusahusa sim mano, mas pra mim, eu sempre prefiro evitar uhashusahusa
Sempre usava o automapper na intenção de poupar tempo, ao invés de mappear manulmente, mas vendo seu video vou repensar o uso dele. Videp top.
Obrigado mano! Repensa aí 🤘🏻🤘🏻
Chegando e deixando o like
Bora codar
Let's Bora!
Concordo contigo, eu era fã do AutoMapper, mas percebi que alguns projetos não estavam mais usando, agora vejo que realmente não é tão vantajoso e não uso mais no meus projetos.
Hahahha exatamente, vamos sair do modo automático, isso mais atrapalha que me ajuda, Jesuss
Opa, concordo com seu ponto vista não vejo problema em usar o automapper porém se o projeto exige performance eu prefiro não usar porém deixa em aberto para os devs criar os mappers manualmente e acabam criando regras além de mapeamento. Em resumo automapper não são performaticos porém dificulta alguém de adicionar uma regra de negócio no mapeamento e mapear manualmente tem o ganho de performance porém abre margem para adicionar regras de negócio.
Muito bom o conteúdo parabéns 👏🏻
Obrigado por acrescentar sua experiencia mano! Sim, mappers podem ser uteis e tem sua sim proposta, a ideia foi mais explicar o porque de eu achar que as vezes cria um problema ao inves de solução
Achei interessante o conteúdo abordado, e confesso que nunca vi dessa perspectiva porque nunca levei em consideração atualizar um objeto existente com automapper, eu realizo sempre a criação do objeto por ele as vezes, e quando preciso atualizar os dados eu faço isso por métodos na classe, eu acredito que dessa forma fica mais claro as responsabilidades de cada classe.
O problema do comparador de igualdade para collections também nunca passei por ele pela forma que sempre trabalho, mas é bom conhecer que esse problema existe e tem solução.
Minha posição é similar a sua, para projetos pequenos não vejo relevância no uso do automapper, mas para os projetos maiores na minha visão faz sentido por conta da repetição de código e por configurar isso uma só vez, apesar dos problemas em runtime que podem aparecer e só são pegos por teste de integração.
A dificuldade maior está em compreender alguns imprevistos no uso pela forma que a ferramenta funciona, pelo debug que não é tão simples as vezes exigindo vários breakpoints nos construtores, e pela flexibilidade durante o mapeamento que quando feito por método estático é bem maior na minha opinião.
É tudo uma questão de tamanho do projeto para mim.
Essa é só minha opinião.
Excelente vídeo
Mas a ideia de configurar uma só vez, não faz sentido criar um método separado? Isso também seria uma só vez 🤘🏻
Duas perguntas aqui, pq não passar no construtor da entidade o DTO inteiro e tratar a conversão dentro dele como "new Pessoa( pessoaDTO )"? E recentemente eu li um artigo sugerindo usar Implicit Operator pra tratar as conversões, o que vc acha disso?
Essa é uma alternativa também mano! Não vejo problema de fazer para DTO para Entidade. Implicit operator eu gosto de usar nesses casos também, faz sentido, mas nesse caso a declaracao, fica melhor sem var, tipo, Pessoa pessoa = pessoaDtoObj... Faz sentido também lenda!
começar pelas entidades é um caminho sem volta kkkk mas assim, por que você usa uow no lugar de repository? Considera mais objetivo?
Cara, eu não sei deixei transparecer isso, mas eu não uso UOW no lugar de repository, eu acredito que um acrescenta ao outro, eu usaria ambos juntos, a unica ideia que eu tenho hoje, é que na maioria das vezes eu não implemento repository pois isso meio que tira o poder do EF, e outra, o EF já implementa repository, é como fazer uma abstração da abstração...
Isso é papo para outro video sauhshauhuas Tmjj meu irmão!
pois é, quando vc perde mais tempo com a semântica de um Automapper ao invés de focar no modelo de negócios e suas melhorias, ai complica.
Na minha experiência, mappers dão muitos problemas e quando tu tem que configurar um de alguma forma muito especifica da muito mais dor de cabeça do que fazer na mão haha.
Bom vídeo abrcs.
Mano isso é muito real ashuhusauhsa como mencionei no video, já passei muito por isso!
Ótimo, nem vou usar 👏
SHuahussahushuahusahusa consegui convencer mais um eu acho auhshusahusahu
Também não vou usar, só se o projeto já estiver usando.
Cara, a treta é que maioria dos projetos já tem o AutoMapper rodando, aí vc acaba caindo nesses cenários de ter que criar inúmeras regras dentro das configs dele.
Sobre o que vc comentou no final, fiquei em dúvida, pq vc não curte muito o padrão repository?
Cara, isso é papo para outro café, na verdade eu não consigo ver valor no padrão repository quando é usado com Entity Framework, eu vejo que a gente perde poder do Entity fazendo isso.
Opa, legal sua visão e concordo com vc, veja bem, seu contexto é um modelo simples. Agora o projeto tem um objeto que tem vários itens e cada itens tem um subitem. Exemplo: Despesa -- ItensDespesa----Pagamentos, somente um DTO para o front demonstrar... AutoMapper vai ajudar e muitooo, nao concorda ? Por favor exemplifique isso pra gente seria um ganho gigantesco no meu conhecimento.
Sim e não ao mesmo tempo, pq eu imagino o tanto de config que deve ser criado para ele entender essas relações, ainda sim, não vejo valor no AutoMapper, pois se ocorrer um erro de mapeamento vai ter que estudar mais ainda a ferramenta para configurar, acho besteira... Dependendo da configuração também, ele não irá trazer somente os campos a serem mapeados, iria provavelmetne trazer todos os campos e após isso fazer o mapeamento, o que não vale muito a pena também
Já utilizaram o mapster? É uma linha de código e não tem que configurar nada, só instalar a biblioteca e acabou.
Não uso mapper tbm