always use separate network and db models

Question

elizarov · Answer

But what is the point Use can autogen all this boilerplate but then reading it What is the purpose

ursus · Answer

Point of having separate models Usually network doesnt return model exactly how I want it for example like enums youd have val fooString and val foo Foo and other things like that also if its a db entity you need ignores for certain properties etc

elizarov · Answer

I see That is what we are trying to solve with `kotlinx serialization` The goal for it to be flexible enough so that you can directly use what you get from it

ursus · Answer

how would that work To skip that network model and get val foo Foo right away

elizarov · Answer

Yes

elizarov · Answer

That is how we ve written the KotlinConf app There is just one data model

ursus · Answer

so competitor to json parsers

elizarov · Answer

no boilerplate

elizarov · Answer

Yes

ursus · Answer

I see cool

ursus · Answer

Btw some people advocate using even more models i e model per layer I usually dont go that far but that network gt db model is almost always present

ursus · Answer

but I for sure support your effort I always feel dirty spamming new instances

elizarov · Answer

That is not a Kotlin approach We try to reduce the boilerplate Write less code more substance

ursus · Answer

Well Id argue that its scoping rather then boilerplate you give a layer only a model it needs

elizarov · Answer

It is a boilerplate when you have to change multiple classes to add a single properly to your data model Kotlin provides you with other means to do scoping of your code

ursus · Answer

hence I only use it usually on network gt db interface

elizarov · Answer

Hopefully we ll be able to solve it for DB too `kotlinx serialization` was designed with DB mapping in mind too

ursus · Answer

but better example would be something like states this is from a project I worked on voice calling I have a CallManager which had a reference to SipCallManager to which umong other things it proxied the makeCall answer etc function calls SipCallManager emitted SipCallState val call Call

ursus · Answer

where Call is a C native thing needs to be released etc I dont want to expose it to the public and most likely public only cares about who is calling so mapping the call address to Contact type so basically CallManager mapped SipCallState val Call to CallState val Contact and exposed that to public this is what they usually mean by models per layer