Рассматривая ваши требования и заявления, я сделал несколько предположений, прежде чем начать писать свое видение возможного решения:
- Вы используете один и тот же класс для извлечения (тип возвращаемого значения операции «чтение») и обновления элемента (тип входного параметра операции «обновление») в службе WCF.
- Ваша текущая проблема реализации заключается в том, как использовать исходный класс (не словарь) И все же иметь возможность определять «что изменилось по сравнению с чтением», когда вы получаете операцию «Обновление», вызываемую в вашей службе WCF
- Вы пишете как сервер, так и клиент. Оба написаны с использованием MS .Net Framework.
Если это так, проблема заключается в отсутствии информации о методе обновления. Требуемая информация «изменилась», что может быть выведено, если присутствует 2-е состояние для сравнения или оно уже должно присутствовать рядом с состоянием, которое необходимо обновить в серверной части.
Поскольку у вас есть только «внутреннее состояние» (без флагов), когда клиент отправляет свои данные в службу WCF, как нам определить, что изменилось? Очевидно, что мы хотим предотвратить повторное чтение, чтобы получить текущее состояние сервера и начать сравнение.
Отправка исходного и измененного состояния с клиента на сервер является возможным, но сложным решением. Кроме того, клиент не заинтересован в этой информации, сервер.
Сложив все это, я полагаю, что изменение типа входного параметра операции «Обновить» - самый простой способ. Создайте класс декоратора, который добавляет поведение «грязного бита» к исходной сущности. Используйте этот новый класс в качестве входного параметра для операции «Обновление». После этого у вас будет возможность проверить этот грязный бит рядом с полным состоянием, отправленным клиентом. Основное изменение на стороне клиента заключается в том, что объект, необходимый для операции «Обновление», больше не совпадает с объектом, предоставленным методом «Чтение». Чтобы облегчить эту боль, я бы, вероятно, создал класс декоратора, который добавил необходимую обработку «грязного бита». Это требует только изменения экземпляра объекта при сохранении подписи интерфейса для клиента (очень мало изменений кода).