Say Goodbye to Repetitive Mapping Functions in Kotlin - Introducing The KConMapper KSP Plugin

Поделиться
HTML-код
  • Опубликовано: 26 ноя 2024

Комментарии • 15

  • @swaminathbera6407
    @swaminathbera6407 5 месяцев назад +1

    Amazing teaching, doesn't expect that you know everything beforehand 😀

  • @vengateshm2122
    @vengateshm2122 Год назад

    Thank you for creating a library to avoid this repetitive task of writing mapper function. Great contribution from you. Kudos!

  • @inertia_dagger
    @inertia_dagger Год назад +1

    this is great! I wanted to implement something like this myself, because I'm tired of writing mappers in "clean code" codebases

  • @DeliOZzz
    @DeliOZzz Год назад +1

    This approach would work like a charm for the small projects or a single module projects. In other case you'll introduce dependencies in your domain module on the data layers, which is not so good, obviously.

  • @willi11319
    @willi11319 Год назад +1

    Exactly what I was looking for!

  • @alphacoder3822
    @alphacoder3822 Год назад +1

    Hey bro your videos are on point and great. Keep posting buddy. Numbers will come. Keep up the grind

    • @yanneckreiss
      @yanneckreiss  Год назад +1

      Thank you for your kind words, that really motivates me 🙂

  • @atibenglobalsynergy
    @atibenglobalsynergy Год назад +1

    Thank you so much for this

  • @galaxiegalaxie5003
    @galaxiegalaxie5003 6 месяцев назад

    Nice work. Does this support kotlin multiplatform.Thank you.

  • @j2shoes288
    @j2shoes288 Год назад +1

    In the clean code arch. , you have one way dependencies. So, the data layer knows about the domain layer, but not vice versa. So, you should have the converter functions inside the data layer, not domain layer since, the domain layer doesn't know about Dto and Entity, but, the Dto and Entity know about the domain layer .

  • @SanjayVerma-mf4ch
    @SanjayVerma-mf4ch Год назад +1

    Actually, this is very interesting.

  • @xSugknight
    @xSugknight Год назад

    In your case, couldnt you simply define User as an interface, implement it once (lets say UserImpl) and UserDTO and UserEntity could just take a UserImpl via delegation? No extra library/annotations required and a guarantee that your implementations all follow the contract of the inferface

  • @CarstenHagemann1
    @CarstenHagemann1 Год назад

    We do have really simple mapping classes like that, but often there's at least one conversion. So I don't see the immediate benefit of this for me/my team

  • @j2shoes288
    @j2shoes288 Год назад

    No, this is a BAD ( useless ) library. It's OBVIOUS why. Imagine an entity class ( db ) without db annotation? Imagine a network model ( Dto ) without network ( gson, moshi, jackson etc ) annotations?

    • @code.visible3066
      @code.visible3066 Год назад +2

      You didn't understood the approach correctly,,,, Your DTO/Entity class will stands where It is,,,, this library gives you mapper functionality like we do it manually..... It. has nothing to do with DTO/Entity annotation....