Я раньше имел основной класс Объекта, обеспечивая Грязную/Удаленную Логику.

При записи подклассов Объекта, Вы могли сделать что-то как:

public string Name
{
    get { return name; }
    set { setValue("Name", value); }
}

Это хорошо работает, но имеет 'ужасную строку' болезнь...

Сегодня можно использовать Лямбда-выражения для исключения строк:

set {setValue(x => x.Name, value);}

Или, и я думаю, что это - лучшее решение, Вы могли использовать AOP:

https://www.postsharp.net /

Таким образом, можно определить действия Атрибутами. Вы создаете атрибут и указываете, что, когда пользователь изменяет связанное свойство, объект становится грязным.

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

Я создал класс, названный DirtyValue<T>, который имеет исходное значение и текущее значение. На его первом использовании это устанавливает и исходное значение и текущее значение. Последовательные вызовы только устанавливают текущее значение.

можно сказать, изменилось ли это путем сравнения этих двух с bool свойством только для чтения под названием IsDirty (). Используя эту технику можно также получить доступ к исходному значению также.

Если Вы устанавливаете "грязный" флаг, понимают, что Вы сохраняете состояние. В какой-то момент необходимо принять меры на основе того состояния, иначе Вы не должны были бы сохранять флаг. Таким образом, вопрос затем становится: там другой путь состоит в том, чтобы инициировать необходимое действие? Отправка сообщений некоторого вида? Кто использует "грязное" состояние и принимает меры и там более чистый интерфейс для того уведомления?

В некоторых ситуациях с задачей устройства записи данных и независимой задачей читателя, я дал каждую задачу updateCount переменная. Производитель увеличивает его количество каждый раз, когда оно пишет. Каждый раз, когда читатель просыпается и находит его количество меньше, чем количество производителя, оно делает обновление с текущими значениями. Вам нужно немного специальной обработки для встречного переполнения, но это довольно просто реализовать.

я успешно использовал эту технику на моделированиях - где производитель является циклом физики, и средство чтения является 3-м дисплеем.

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

Интересная альтернатива явному dirty=true подход, хотя это - вероятно, излишество для большинства ситуаций и часто не применимое, должна была бы использовать защитные страницы. Установите страницу памяти как только для чтения (например, с VirtualProtect () в Windows) и поймайте сигнал/исключение, когда программа попытается записать в страницу. Сделайте запись, что страница была изменена, затем изменяет флаги защиты страницы к выполнению резюме и перезаписываемому.

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

Вы можете захотеть посмотреть на переопределение gethashcode и равнозначное методам ваших доменных объектов и хранение оригинального хэшкода в хэш-таблетке по объектным ключам. Затем создайте процесс, который примет объект, найдет его ключ в хэш-таблице и сравнит значения хэшей.

• Если хэш одинаков, то изменений нет. (не отправляйте в хранилище или базу данных)
• если хэш отличается, то у объекта есть изменения. (обновление)
• Если ключ не найден, то объект новый. (insert)
• Не знаю, как определить, нужно ли удалять объект, кроме процесса удаления по запросу и не используя для этого отслеживание хэш-кода.

Я не пробовал этого, и хэш-табл может быть не лучшим способом отслеживания ключей/значений хэша объектов. Это сохранит память, отслеживая только хэш-коды и ключи. Я не уверен на 100%, но думаю, что некоторые операторы могут использовать этот метод в своих контекстах данных/объектах отслеживания.