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

[@swaminathbera6407]

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

[@vengateshm2122]

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

[@willi11319]

Exactly what I was looking for!

[@DeliOZzz]

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.

[@inertia_dagger]

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

[@alphacoder3822]

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

[@yanneckreiss]

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

[@atibenglobalsynergy]

Thank you so much for this

[@galaxiegalaxie5003]

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

[@j2shoes288]

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]

Actually, this is very interesting.

[@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]

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]

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]

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....