always use separate network and db models

# announcements

[ursus]

always use separate network and db models

[elizarov]

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

[ursus]

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]

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]

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

[elizarov]

Yes

[elizarov]

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

[ursus]

so competitor to json parsers?

[elizarov]

(no boilerplate)

[elizarov]

Yes

[ursus]

I see, cool

[ursus]

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

[ursus]

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

[elizarov]

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

[ursus]

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

[elizarov]

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]

hence I only use it usually on network -> db interface

[elizarov]

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

[ursus]

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]

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