[boost] Re: Proposal: Persistence framework

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-06 14:09:11

> -----Original Message-----
> From: Kevlin Henney [mailto:kevlin_at_[hidden]]
> Sent: Monday, March 06, 2000 12:52 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Proposal: Persistence framework
> 
> 
> In message <7D72C1B2F7A3D21191F8006097149AC0A89D5E_at_[hidden]>,
> Borgerding, Mark A. <MarkAB_at_[hidden]> writes
> [...]
> >       1) separates data from persistence media
> [...]
> >Separate the data from the method of persistence.
> >Each must belong into it's own class hierachy.
> > 
> >So the following hierarchies might exist in your project
> > 
> >(Base classes )        (Subclasses )
> > 
> >                  /---- car
> >PersistentData <------- employee record
> >                  \---- email message
> > 
> > 
> >                    /--- file
> >PersistenceMeans <-------- database
> >                    \--- socket
> [...]
> 
> Based on work I did in the past, you may also wish to 
> consider breaking
> the means up: the media (eg file, socket) and the representation (eg
> native binary, text, CDR). This allowed the representation to 
> be treated
> as orthogonal to the media mechanism.

I like this idea.  A sort of traits class for the representation.  I think
that it might be best implemented at the level of subclass of
PersistenceMeans, since the data object should not really care about
anything except how to describe its structure to the abstract
PersistenceMeans interface.  Another reason to implement it at this level is
because some persistence means may not have options when it comes to
representation. For a database, the representation is dictated by the table
layout.  For text files, the representation may be limited to printable
characters.

> 
> Also, I would question having to tie everyone into a hierarchy at all.
> They can choose to do so if they wish, but a generic 
> interface approach
> should also be supported. To implement this PersistenceMeans needs to
> support a member template that then wraps up its argument in a generic
> adapter, ie PersistentData <---- PersistentDataAdapter<T>, so it's a
> generic to an inheritance interface adapter.

Unfortunately I snipped some stuff out of my post that addressed this issue.

The data object does not have to derive from PersistentData. It is
sufficient to support the interface (i.e. have all the functions expected of
a PersistentData object.  An adapter would "marshall" the calls onto its
templated reference class.  This way the class hierarchy can be kept clean,
while still allowing the data object to be treated as a PersistentData
object.

The implementation of the adapter is pretty simple. e.g.

template <class T> // T does not need to derive from anything, but merely
support the interface functions
class PersDataAdapter : public PersistentData 
{
public:
        PersDataAdapter(T & t):ref(t){}
        std::string GetTypeName() const { return ref.GetTypeName(); }
          void DescribeDataTo(PersistenceMeans & refPm) {
ref.DescribeDataTo(refPm); }
// ...
private:
        T & ref;
};

I must admit that the adapter functionality rarely got used, even though it
was in the framework from the start and fairly well documented.