В настоящее время я работаю над бизнес-приложением, написанным на C ++ с базой данных Postgres для персистентности.
Логика приложения построена из доменных объектов, которые необходимо сохранить.
В идеале не должно быть логики постоянства в объектах домена. Загрузка, сохранение и удаление объектов из базы данных осуществляется с использованием класса data-mapper.
Сохранение новых объектов, загрузка существующих объектов и удаление объектов из базы данных кажется тривиальным. Моя задача — сохранить изменения объектов обратно в базу данных (другими словами, sql-updates, а в случае добавления новых элементов в список — sql-вставки этих элементов).
Я рассматриваю возможность использования вычисления для каждого объекта домена, чтобы определить, был ли объект изменен с момента его создания (все объекты домена создаются за один шаг через конструктор).
Шаблон будет выглядеть примерно так:
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);
}
};
К сожалению, функция Calculate_checksum () должна быть более сложной, чем просто вычисление контрольной суммы по ‘this’. Контрольная сумма должна быть рассчитана относительно реляционной модели (не объектно-ориентированной модели). Например, если у сущности есть переменная-член типа vector, отношение в реляционной базе данных будет храниться «в обратном порядке» (то есть SomeOtherEntityType-Table будет иметь внешний ключ в Entity-table). Таким образом, векторы других сущностей необходимо будет игнорировать при расчете контрольной суммы. (Возможно, это можно решить с помощью генерации кода в заголовочных файлах, которые определяют классы сущностей).
Что вы думаете об этом? Это плохая идея, и если да, то почему?
Существуют ли другие продукты, которые работают аналогичным образом в отношении ORM и отслеживания изменений в доменных объектах?
Задача ещё не решена.
Других решений пока нет …