Почти каждый программист сделал это один раз в своей жизни: установил некоторый флаг, если изменилось значение переменной. Там всегда много свойств, и вы хотите отслеживать, если что-то изменилось
Я заинтересован в различных способах реализации функциональности "грязного флага" для вышеупомянутых ситуаций, кроме того, что флажок стандартного объекта с грязным флагом обновляется при каждом изменении свойства. Там должно быть что-то лучше, чем положить "грязный = истинный" в каждый сеттер: он просто выглядит уродливым и утомительным.
Для моего DAO я сохраняю копию исходных значений, полученных из базы данных. Когда я отправляю его для обновления, я просто сравниваю исходные значения с текущим. Это стоит немного в обработке, но это намного лучше, чем наличие грязного флага на каждое свойство.
EDIT, чтобы еще больше оправдать отсутствие грязного флага: если свойство возвращается к его первоначальному значению, нет способа отразить это, грязный флаг продолжает быть грязным, потому что исходное значение было потеряно.
У меня был базовый класс Entity, предоставляющий Dirty/Removed Logic.
При написании Entity-подклассов вы можете сделать что-то вроде:
public string Name
{
get { return name; }
set { setValue("Name", value); }
}
Это прекрасно работает, но имеет болезнь "уродливой струны"...
Сегодня вы можете использовать выражения Lambda Expressions для исключения строк:
set {setValue(x => x.Name, value);}
Или, и я думаю, что это лучшее решение, вы можете использовать AOP:
Таким образом, вы можете определять действия по атрибутам. Вы создаете атрибут и указываете, что, когда пользователь изменяет связанное свойство, объект становится грязным.
Кроме того, вы можете сохранить список свойств в своем классе (базовый Entity), который будет помнить измененные свойства и получить доступ к этому списку из вашего кода AOP.
Я создал класс под названием DirtyValue<T>, который имеет исходное значение и текущее значение. При первом использовании он устанавливает как исходное значение, так и текущее значение. Последовательные вызовы устанавливают только текущее значение.
Вы можете узнать, изменилось ли это, сравнив два, с свойством readonly bool, называемым IsDirty(). Используя этот метод, вы также можете получить доступ к исходному значению.
Если вы устанавливаете "грязный" флаг, понимаете, что вы сохраняете состояние. В какой-то момент вам нужно принять действие на основе этого состояния, иначе вам не нужно будет держать флаг. Итак, тогда возникает вопрос: есть ли другой способ инициировать необходимое действие? Отправка сообщений какого-то рода? Кто потребляет "грязное" состояние и принимает меры, и есть ли более чистый интерфейс для этого уведомления?
В некоторых ситуациях с задачей записи данных и задачей независимого чтения я дал каждой задаче переменную updateCount. Производитель увеличивает свой счет каждый раз, когда он пишет. Всякий раз, когда читатель просыпается и считает, что его счет меньше количества производителей, он обновляет текущие значения. Вам нужна небольшая специальная обработка для переполнения счетчика, но это довольно просто реализовать.
Я успешно использовал этот метод в симуляциях - где производитель - это физический цикл, а читатель - это 3D-дисплей.
Я бы поместил change() в каждый сеттер, т.е. вызовет частный метод вместо простого изменения флага. Затем этот метод может устанавливать флаг или выполнять любую обработку, например. он также может уведомлять обо всех наблюдателях.
Интересная альтернатива явному подходу dirty=true, хотя она, вероятно, слишком сложна для большинства ситуаций и часто неприменима, будет использовать защитные страницы. Задайте страницу памяти как доступную только для чтения (например, VirtualProtect() в Windows) и поймайте сигнал/исключение, когда программа пытается записать страница. Сделайте запись о том, что страница была изменена, затем измените флаги защиты страницы на запись и возобновите выполнение.
Это метод, обычно используемый операционными системами для определения необходимости записи страницы в файл подкачки, прежде чем она будет выведена из ОЗУ.
Возможно, вы захотите взглянуть на переопределение gethashcode и равные методы ваших объектов домена и сохранить исходные хэш-коды в хэш-таблице с помощью ключа объекта. Затем создайте процесс, который берет объект, находит его ключ в хеш-таблице и сравнивает хеш-значения.
Я не пробовал это, и хеш-таблица, возможно, не лучший способ отслеживать ключи объектов/хэш-значения. Он сохранил бы mem, только отслеживая только хэш-коды и ключи. Я не уверен на 100%, но я думаю, что некоторые ормы могут использовать этот метод в своих объектах контекста данных/отслеживания.