I am currently working on a business application written in C++ with a Postgres database for persistence.
The application logic is built with domain objects which need to be persisted.
Ideally, there should be no persistency logic in the domain objects. Loading, saving and deleting objects from the database is done using a data-mapper-class.
Saving new objects, loading existing objects and removing objects from the database seems trivial. My concern is saving object changes back to the database (in other words sql-updates, and in the case of adding new elements to a list, sql-inserts of those elements).
I am considering using a calculation on each domain object in order to determine if the object was changed since its construction (all domain objects are constructed in one step, via the constructor).
The pattern would look something like this:
class Entity {
protected:
int id;
uint32_t current_checksum() {
// calculation here (boost::crc32, md5)
}
uint32_t original_checksum;
public:
Entity(const int id) :
id(id) {
original_checksum = current_checksum();
}
bool is_dirty() const {
return (current_checksum() != original_checksum);
}
};
Unfortunately, the calculate_checksum() function would need to be more sophisticated than simply calculating checksum on 'this'. The checksum would need to be calculated with respect to the relational-model (not the object-oriented model). For instance, if the entity has a member variable of type vector, the relation in a relational database would be stored 'in reverse' (that is, the SomeOtherEntityType-Table would have foreign key into Entity-table). So, vectors of other entities would need to be ignored when calculating the checksum. (This could probably be solved by using code-generation on the header files which define the entity-classes).
What are your thoughts on this? Is it a bad idea, and if so, why?
Are there other products out there which operate in a similar fashion with respect to ORM and tracking changes to domain objects?
Aucun commentaire:
Enregistrer un commentaire