Programming

18101 readers

56 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

How do you structure your models save/load code? (lemmy.pe1uca.dev)

submitted 2 days ago by [email protected] to c/[email protected]

9 comments fedilink hide all child comments

I have in mind two options:

Code in the class being saved/loaded. The flows for each entity/model are in the same place, so it's easy to just have one file open to see all the functionalities of that class, but this means having more code in a single file.
Code in a dedicated class (like a factory)
This makes each file smaller, but spreads flows of a single model into different parts of the repo, also because I'm thinking of having a directory /src/models and another like /src/export (or serialize)

What do you guys think?
What's your preferred way to organize the save and load flows?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 2 days ago

First option for small codebases. Second option when you know your codebase will grow large enough to break things apart into multiple packages.

The thing is, you typically need dependencies for de-/serialization. You only want those dependencies in the parts of the codebase that actually do the de-/serializing. And your model will likely be included in pretty much everything in your codebase, so the de-/serializing code should not be in there.
Well, unless your programming language of choice supports feature flags with which the de-/serializing code + dependencies can be excluded from compilation, then you can think about putting it into the model package behind a feature flag.