Looking at the issue of how to declare the binding functions, what I had proposed below (which is what I did in DTL) is remarkably similar to the functions required by the boost serialization library so it really might make sense to leverage off of that as pointed out earlier. There are a few "extra" things we do in DTL binding that I don't see in the serialization library which should be highlighted though: 1. Binding types. If you want to execute a stored procedure then when you bind a column or parameter you have to store information about the binding type (input, output, in/out). 2. Validation / final construction before save and load. In DTL, after the members in a class have been initialized from the database, we optionally allow the users to associate a validation function that can be used to perform any final class construction tasks including how to handle NULL fields. So e.g. we might have a class like: class { string Location; bool Location_is_null; double TempInCentigrage; double TempInFarenheit; } In the database, only Location and TempInCentigrade will be stored. When the class is initialized from the DB, only these two fields get set and we call a UserValidate() function to let the class finish constructing and initialize the rest of its internal state. Here is a link to the DTL documentation for further examples, we call this function SelVal there: http://dtemplatelib.sourceforge.net/SelVal.htm Similarly, we also have an InsVal that enforces any final validations or calculations that need to be performed prior to writing to the database (auto-generated keys are one common application, as are policies on how to handle NULL values). Honestly, I'm kind of surprised that boost:serialization does not have a similar concept, it may be that I just didn't look hard enough through the docs.