Models should contain or inherit their own serializers/deserializers.

Either put the generic serialization in a base Model class, or make the base Model class defer implementation to a reusable Serialization helper class, preferably an off the shelf library.

Usually the serialization/deserialization code, I keep with the model. The part where a file or whatever comes in, I leave that to the caller to decide on. In other words, the model knows how to serialize and deserialize itself, but not where it’s being serialized to or deserialized from.

Then again, in C#, it’s usually just a couple attributes on my model, and in Rust, it’s usually just a couple derives. It’s rare I actually write much, if any, serialization logic by hand.

Storage concerns should be separate from the data model.

Usually my models only store data, meaning the files that contain them don’t have much code. The decision also depends on the tools you are using and who you are working with. I would fallback to the rule of separation of responsabilities and write a new class for the purpuse of serializing the model (which could and should also serialize similiar models). This way is universal in any language and can easily be understood by future you and colleages.

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.

Related code should go together as much as possible, for maintainability.

If this results in too much code together, it’s time to think about other ways to structure the code so that each thing the user can do fits into as few files as possible, but not too many things the user can do share a file.

First option for each object. Unless things get bigger/tons of serializers/etc… then we move to the second-ish model.

To be honest, I usually just use whatever the framework has as best practices so that when new team members get on-boarded, theres less friction.

mainly java dev here:

if i only have few classes i want to serialize/deserilize i implement the logic for that in the class, if they need special logic for that, and implement the serilizable interface. writing objects to somewhere or reading them from somewhere belongs in a different class.

if i have a lot of classes or use a framework like spring i’ll employ whatever they offer for serilization and deserilization or more likely a databinding library like jackson.

other languages with classes or structs offer simmiliar options(pythons pickling and unpickling or the json package in their standardlib for example) so my approach would stay mostly the same.

In python I put my base models in models/__init__.py. The bases have things for managing data behind the scenes, adding common utility methods, etc. If I’m using another library or method to serialize data I’d put it in a separate utility script somewhere, it’s probably going to be useful to more than just data models and it’s easy enough to import.

Then each file that defines models has a from models import BaseModel or whatever else is needed, keeping each file relatively short and focused to what it needs to do.