Encapsulation is only somewhat more protective than simply adding a version number on the file format. Not that it isn't helpful from a project-management standpoint, but in the really complicated cases(real world example: serializing the state of a video game down to the exact frame - many of the entities want to reference each other, numerous static resource hooks, etc.), there's an impedance at the moment you decide to serialize, and the design challenge is mainly one of deciding where to attack it:
1. By doing reflective magic (potentially a lot of it) at the moment of serialization so that a serialization-friendly form can be teased out. If you are not working within a reflective environment, this option doesn't exist without additional effort. And if the runtime changes the magic breaks.
2. By "primitivizing" the runtime so it's closer to the serialized representation, at the expense of dirtying the codebase to exchange e.g. object references for id numbers. You can make it look prettier again by enforcing conventions, but the extra weight is still there. Adding reflection within an environment that didn't have it built-in also requires going through this step.
Those two options are the design tradeoff. And the bigger your serialization ambitions go the more the pressure builds to either massively primitivize(e.g. use a SQL database for all data and make the special runtime representations non-persistent always) or make an image so that data never "actually" leaves the runtime.
In electing to use a database layer everywhere, web apps have more-or-less standardized on primitive designs, and subsequently try to claw back readable code through tricks like ORMs and DSLs.
1. By doing reflective magic (potentially a lot of it) at the moment of serialization so that a serialization-friendly form can be teased out. If you are not working within a reflective environment, this option doesn't exist without additional effort. And if the runtime changes the magic breaks.
2. By "primitivizing" the runtime so it's closer to the serialized representation, at the expense of dirtying the codebase to exchange e.g. object references for id numbers. You can make it look prettier again by enforcing conventions, but the extra weight is still there. Adding reflection within an environment that didn't have it built-in also requires going through this step.
Those two options are the design tradeoff. And the bigger your serialization ambitions go the more the pressure builds to either massively primitivize(e.g. use a SQL database for all data and make the special runtime representations non-persistent always) or make an image so that data never "actually" leaves the runtime.
In electing to use a database layer everywhere, web apps have more-or-less standardized on primitive designs, and subsequently try to claw back readable code through tricks like ORMs and DSLs.