Bonjour, please tell me why my bad idea is indeed ...

# serialization

[jmfayard]

Bonjour, please tell me why my bad idea is indeed bad

So I am doing lots of SQL and to decouple sql entities from domain classes,
I have to write tons of dummy mappers from say UserProfileEntity (sql) to UserProfile who have the same properties
And I'm bored to write those mappers manually
In the .Net world, there is http://automapper.org/ for that
I wonder I could just leverage kotlinx.serialization
to transform UserProfileEntity to JsonElement and back to UserProfile

[Javier]

Maybe the problem is how the framework is working

[Javier]

Imagine you don't want to mark as serializable your model because it is on "domain", but Kotlin Serialization allows you to create a serializer so you don't have to duplicate the model.

That SQL framework doesn't allow that? Because probably the mapper is a feature that should be on it

[Casey Brooks]

I’ve had the same thought before, I don’t think it’s a terrible way to go about it. You end up with 2 copy operations instead of 1 with a straight transformation, but it might be worth the performance hit since SQL models are usually fairly simple.

The reason I probably wouldn’t do it is that you’d basically be left with a UserProfile model that is essentially the same schema as the SQL table it comes from. You’re left with a similar problem of needing to update UserProfile if UserProfileEntity changes. So even though you’re not coupled to the DB model class itself, you’re still tightly coupled to the DB.

Plus, it doesn’t give you much room to improve the UserProfile model for easier use (make it more type-safe, group related properties into nested objects, resolve IDs to concrete objects during mapping, etc). And any such transformations would probably be much harder to maintain with Serialization annotations or custom serializers than the simple, hand-written mapper functions. Not to mention that if you allow yourself to fallback to hand-written mappers, then you’re just fragmenting your code, making it harder for new developers on the project to know what they should be doing.

[jmfayard]

I'm using Jetbrains exposed, it's not concerned about entities it works at a lower level

[jmfayard]

Thanks a lot for your answer

[Casey Brooks]

FWIW, I think the kotlinx serialization JsonElement can work very well as an intermediate stage in data-heavy use cases. They’re lightweight, immutable, easy to work with, multiplatform, and easy to debug. I’ve been experimenting with using it for generating large forms in Compose, https://github.com/copper-leaf/kotlin-json-forms.

Thinking of it in a similar way: convert a concrete domain model to JsonElement, make changes to the data with this library, then convert the updated JSON back into the original (or another) model, all without needing to make a bunch of mapper functions by hand.

[jmfayard]

oh yes writing a mapper JsonElement -> JsonElement makes sense to add flexibility!

[Robert Jaros]

Perhaps you could check https://github.com/krud-dev/shapeshift

[mbonnin]

to decouple sql entities from domain classes,

I have to write tons of dummy mappers from say UserProfileEntity (sql) to UserProfile who have the same properties

My 2 cents: if you're doing this automatically, you're introducing the coupling back. If something changes in your SQL, you'll have to change your domain class

[joschi]

ShapeShift looks nice. 🙂

In the Java world there's MapStruct for this.

Here's an example how to use it with Kotlin:
https://github.com/mapstruct/mapstruct-examples/tree/main/mapstruct-kotlin

[jmfayard]

thanks but I hate kapt and managed to keep it out of my project until now 🙂