C++ Design pattern for IO operations

Question

I want to develop an app that need to retreive data from an external data source (Database/Files/...) and I can't find a good pattern to do so.

Assuming I have the following structure in a database:

• VariableTypeTable: id + some stuff
• VariableTable: id + some stuff + a reference to a VariableTypeTable

I probably want 3 classes:

• VariableType that encapsulate VariableType stuff
• Same for Variable
• VariableManager to manage my object lifetime + and some business operations (search, etc..)

Is there a common pattern for loading data ? Where and how should I handle IO operations ?

Some thoughts:

• Variable and VariableType should not know (or at least do) anything about IO.
• Maybe the VariableManager could provides some IO operations but I'll have business logic and IO at the same place (breaking SRP ?).
• If I split the Manager and the IO operations how can I keep sync ? For example, creating a new variable should add the variable in the database and keep the manager updated.
• Injecting some interface VariableManagerIO into VariableManager to handle IO and only manipulating the Manager. How should I report IO error ?

Edit:

The example I gave is over-simplified but my main problem goes beyond reflexion/persistency.

I'm also extending the question a little bit. What if some business function need to query data because it is simpler (for example with a complex SQL request).

Answer 1

It sounds like you're looking for some style of database persistent object. If you do a google for c++ database persistence you'll get some hits. I'm not familiar with any of those libraries.

This is a more complicated subject than it may seem. There have been countless persistent object systems over the years. I've used about a dozen (out of probably hundreds). They have all sucked in one way or another, but you can usually get the job done with any of them.

I roll my own. I can write PSQL object handling in my sleep, and I usually write a modeler tool and a code generator. I keep it simple.

The objects themselves don't know they're being persisted. They don't know they might be stored in a database. I use a parallel set of classes for reading and writing them. They MAY, however, know how to use whatever JSON library I'm using, so saving / loading from flat JSON files becomes trivial. Very, very easy to codegen.

One version of this I use for my pet projects is here:

https://github.com/jplflyer/Persist

Which depends upon:

https://github.com/jplflyer/ShowLib

This is very specific for how I do things and assumes PostgreSQL.

---

For managing updates, my tools won't do that for you. You have to know you've made changes and persist them yourselves. That's where all the various persistent object libraries tend to get messy. Some do a better job than others.

I prefer "POJOs" -- which is actually a Java term. Plain Old Java Objects. Well, in this case, Plain Old C++ Objects. Once you start teaching your objects that they live in a database, they get REALLY messy. Because I control how updates happen, I can also just add a call to my persist engine at the same time as an update.

But if you need that automated, maybe one of those links from that google page I suggested up in paragraph 1 will help you.