Architecture of a desktop application persistence model

Question

I am working on a C++ desktop application using the MVC design-pattern. In a nutshell, it allows to monitor the position of a real robot in a 3D environment and create tasks for it by modifying the virtual 3D environment.

Everything in the 3D scene is a "DataObject" with properties and signals when a property change (a bit like a QObject in Qt). We want the user to be able to save the scene in a file to work on it later.

Our DataObject framework is capable of (de)serializing every DataObjets. This is convenient, however, I do not want every DataObjects to be serialized. For instance, the origin marker of the 3D scene or the robot model are DataObjects, but I do not want them to be serialized as I would not be able to update them on old files. E.g. if I make an update where the origin marker is bigger, it wouldn't affect old persistence files.

I first wanted to do a "persistence layer" that will pick the DataObjects we want to serialize. Someone proposed to use the current system but add a "shouldBeSerialized" boolean on every DataObjects.

I am feeling we are not doing things rights. I already read this post and this one, but I am still not sure what to do.

Answer 1

I think that is a good topic. I used to, many many years ago, do stuff like what I think you are describing, these days, but these days less desktop stuff. I think you are on the right track.

I see a couple of things in your description that stand out.

First the MCV. In an MVC the Model and the Data or the Controler and the business logic are only the same in the trivial case. i.e. one your application becomes non-trivial there is a need for a tiered structure where the MVC is just part of the presentation Tier.

(yes i know i am using web application words, but i actually first learn Tiered architecture in the pre-web world)

So if for example if the application is responding to a change event from the view, the controller can call the persistence layer to get the updated "Model" and present the updated view.

and second that you are serializing the terrain, but not the annotations and players. which is fine. but it looks like you have different classes of objects in your scene.

I would consider defining an interface between the presentation tier (MVC) and the underlying logic and data storage (say a partial or pure virtual class package)

Things that you never want to serialize and things that you do want to serialize can be different branches in the class hierarchy. Then if you send all the objects to the persistence layer, define different methods for the different sub classes. you will have a transparent call to an API that will handle things as appropriate.

This also will solve your future problem of data and action version transparency. As your program evolves and more attributes are added. extending the virtual classes should allow you to maintain compatibility between old and new versions of the environment objects.