POR QUE PAREI DE USAR MAPPERS NO Dotnet | C# | MINHA OPINIÃO!

แชร์
ฝัง
  • เผยแพร่เมื่อ 10 ธ.ค. 2024

ความคิดเห็น • 34

  • @FMAlmeidaLeite
    @FMAlmeidaLeite ปีที่แล้ว +1

    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.

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว +1

      Boaaa mano! Agora da próxima você vai pensar duas vezes antes de usar 😅😅

  • @brendonaugusto2558
    @brendonaugusto2558 ปีที่แล้ว +1

    Top mano, muito interessante o conteúdo abordado!! Parabéns pelo ótimo conteúdo

  • @CristianoRaffiCunha
    @CristianoRaffiCunha ปีที่แล้ว +2

    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.

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว

      Sim, maior trampo ali pra configurar uma concatenação de strings 🫠

  • @ewerton3p
    @ewerton3p 7 หลายเดือนก่อน +1

    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!

    • @cristianwilliamdev
      @cristianwilliamdev  7 หลายเดือนก่อน

      UHShuashusahusa sim mano, mas pra mim, eu sempre prefiro evitar uhashusahusa

  • @X3noic
    @X3noic ปีที่แล้ว +1

    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.

  • @cleitonsouza4648
    @cleitonsouza4648 ปีที่แล้ว +2

    Chegando e deixando o like
    Bora codar

  • @pulagrilo
    @pulagrilo ปีที่แล้ว +1

    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.

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว +1

      Hahahha exatamente, vamos sair do modo automático, isso mais atrapalha que me ajuda, Jesuss

  • @canedohimura
    @canedohimura ปีที่แล้ว +2

    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 👏🏻

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว

      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

  • @N0151
    @N0151 ปีที่แล้ว +2

    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

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว +1

      Mas a ideia de configurar uma só vez, não faz sentido criar um método separado? Isso também seria uma só vez 🤘🏻

  • @spakkaaa
    @spakkaaa ปีที่แล้ว +2

    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?

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว

      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!

  • @roneikunkel8625
    @roneikunkel8625 ปีที่แล้ว +1

    começar pelas entidades é um caminho sem volta kkkk mas assim, por que você usa uow no lugar de repository? Considera mais objetivo?

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว

      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!

  • @Leanst.
    @Leanst. ปีที่แล้ว

    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.

  • @marcosferreira17br
    @marcosferreira17br ปีที่แล้ว +2

    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.

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว

      Mano isso é muito real ashuhusauhsa como mencionei no video, já passei muito por isso!

  • @joegpapst2129
    @joegpapst2129 11 หลายเดือนก่อน +1

    Ótimo, nem vou usar 👏

    • @cristianwilliamdev
      @cristianwilliamdev  10 หลายเดือนก่อน

      SHuahussahushuahusahusa consegui convencer mais um eu acho auhshusahusahu

    • @miltontsilva
      @miltontsilva 3 หลายเดือนก่อน

      Também não vou usar, só se o projeto já estiver usando.

  • @castrojunin
    @castrojunin ปีที่แล้ว +1

    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?

    • @cristianwilliamdev
      @cristianwilliamdev  ปีที่แล้ว

      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.

  • @GladsonReis
    @GladsonReis 11 หลายเดือนก่อน

    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.

    • @cristianwilliamdev
      @cristianwilliamdev  11 หลายเดือนก่อน

      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

  • @guilhermealves577
    @guilhermealves577 4 หลายเดือนก่อน

    Já utilizaram o mapster? É uma linha de código e não tem que configurar nada, só instalar a biblioteca e acabou.

  • @Guilhermedores
    @Guilhermedores 2 หลายเดือนก่อน

    Não uso mapper tbm