Класс должен поддерживать интерфейс, но это требует добавления логики к классу навязчивым способом.Можем ли мы предотвратить это?

Question

У меня есть приложение на C ++, которое загружает много данных из базы данных, затем выполняет алгоритмы для этих данных (эти алгоритмы довольно ресурсоемки и интенсивно обрабатывают данные, поэтому я загружаю все данные заранее), затем сохраняю все данныеэто было изменено обратно в базу данных.

Часть базы данных прекрасно отделена от остальной части приложения.На самом деле, приложению не нужно знать, откуда поступают данные.Приложение может даже быть запущено в файл (в этом случае отдельный файловый модуль загружает файлы в приложение и в конце сохраняет все данные обратно в файлы).

Сейчас:

• слой базы данных хочет сохранить только измененные экземпляры обратно в базу данных (не полные данные), поэтому ему необходимо знать, что было изменено приложением.
• с другой стороны, приложениеему не нужно знать, откуда берутся данные, поэтому он не хочет чувствовать себя вынужденным сохранять состояние изменения для каждого экземпляра своих данных.

Хранить мое приложение и его структуры данных как отдельные элементы.насколько это возможно из слоя, который загружает и сохраняет данные (может быть база данных или файл), я не хочу загрязнять структуры данных приложения информацией о том, были ли экземпляры изменены с момента запуска или нет.

Но чтобы сделать слой базы данных как можно более эффективным, нужен способ определить, какие данные были изменены приложением.катион.

Дублирование всех данных и сравнение данных при сохранении не вариант, так как данные могут легко заполнить несколько ГБ памяти.

Добавление наблюдателей в структуры данных приложения также не вариантпоскольку производительность в алгоритмах приложения очень важна (а зацикливание на всех наблюдателях и вызов виртуальных функций может стать важным узким местом производительности в алгоритмах).

Любое другое решение?Или я пытаюсь быть слишком «модульным», если не хочу навязчиво добавлять логику в классы своего приложения?В таких случаях лучше быть прагматичным?

Как инструменты ORM решают эту проблему?Они также заставляют классы приложений сохранять своего рода состояние изменения или они заставляют классы иметь наблюдателей изменений?

Answer 1

Если вы не можете скопировать данные и сравнить, тогда вам явно нужна какая-то запись того, что изменилось.Таким образом, вопрос заключается в том, как обновить эти записи.

Инструменты ORM могут (если они хотят) решить проблему, сохранив флаги в объектах, сообщая, были ли данные изменены или нет, и если да, то что,Звучит так, как будто вы делаете необработанные структуры данных доступными для приложения, а не объекты с аккуратно инкапсулированными мутаторами, которые могут обновлять флаги.

Так что ORM обычно не требует, чтобы приложения отслеживали изменения в каких-либо подробностях,Приложение обычно должно указывать, какой объект (ы) сохранить, но ORM затем решает, что необходимо сохранить в БД для этого, и может применить оптимизацию там.

Полагаю, это означает, что вВ соответствии с вашими терминами, ORM добавляет наблюдателей к структурам данных в некотором смысле.Это не внешний наблюдатель, это объект, который знает, как мутировать себя, но, конечно, есть некоторые накладные расходы для записи того, что изменилось.

Один из вариантов - предоставить «медленные» мутаторы для ваших структур данных, которые обновляютфлаги, а также «быстрый» прямой доступ и функция, помечающая объект как грязный.Тогда приложение будет выбирать, использовать ли потенциально более медленные мутаторы, которые позволяют ему игнорировать проблему, или потенциально более быстрые мутаторы, которые требуют, чтобы оно пометило объект как грязный до его запуска (или после его завершения, возможно, в зависимости от того, чтовы делаете о транзакциях и несовместимых промежуточных состояниях).

Тогда у вас будет две основные ситуации:

• Я зацикливаюсь на очень большом наборе объектов, условно делая одно изменениедля некоторых из них.Используйте «медленные» мутаторы для простоты приложения.
• Я делаю множество разных изменений в одном и том же объекте, и я действительно беспокоюсь о производительности средств доступа.Используйте «быстрые» мутаторы, которые, возможно, напрямую выставляют некоторый массив в данные.Вы получаете производительность в обмен на знание дополнительной информации о модели персистентности.

В компьютерных науках есть только две серьезные проблемы: аннулирование кэша и присвоение имен.

Фил Карлтон