Здравствуйте, Alexander Polyakov, Вы писали:

>>Накопление истории изменений и применение ее на сервере тоже может оказаться громоздким.
AP>Если говорить схематично, история изменений будет накапливаться в виде простой структуры ("Тип LINQtoSQL объекта", "Значение Primary Key-я", "Имя свойства", "Значение свойства"). Возможно, потребуется передача значений всех свойств. Кроме того, будут аналогичные схемы для insert и delete. Еще timpstamp-ы. Но все это будет выполнятся в инфраструктурных классах, и вроде не так уж это сложно получается.

Я вот не пойму никак, а зачем вам все это? Зачем накапливать историю изменений в клиентском контексте в таком странном виде? Когда ее передавать на сервер? Что делать если свойство объекта изменили пять раз подряд и в конце оно приобрело то-же значение, что и до изменений? Что делать если объект добавили в клиентском контексте, а потом сохранили на него ссылки в других объектах, а потом удалилив клиентском контексте, как вы будете разруливать ссылочную целостность при сохранении на сервере? Почему не прердавать сами измененные объекты? У вас в системе кроме данных никакой логики нет? Что если при изменении свойства OrderDTO.Customer система должна отправить email определенного содержания?

По моему вы сейчас на ровном месте создаете себе кучу проблем, которые потом будете героически преодолевать.