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

Есть 3-уровневое приложение: 1) Winforms - 2) IIS+Asp.Net Web Services - 3) SQL Server 2008. Особенность среды - каналы связи между 1) и 2) с низкой пропускной способностью.

Клиент получает с сервера документ на редактирование в виде датасета довольно сложной (десятки таблиц), но древовидной структуры (т.е. циклических связей нет). Естественно, он был на сервере зазипован, на клиенте раззипован. Датасет, вообще говоря, большой (относительно канала связи :)). Пользователь что-то в нём редактирует (как правило, очень немного). Нажимает на кнопку Сохранить.

Мы должны что-то отправить с 1) на 2). Подозреваю, что это должен быть
А) GetChanges() из датасета, сериализированный в виде дифграммы;
Б) Или сам датасет, сериализированный в виде дифграммы?
Естественно, оно перед отправкой на сервер зипуется, а там раззиповывается. На 2) создаётся датасет, тейбладаптеры вносят изменения в таблицы БД (т.е. в 3)).
Вариант зазиповать датасет целиком и на сервере полностью перенакрыть документ в БД поверх существующего не рассматривается по ряду причин.

Но это ещё не всё. Пользователь, вообще говоря, продолжает редактировать документ. И получается, что наш датасет на уровне 1) нужно бы привести к виду, соответствующему 3). Перегружать на клиента весь датасет по-новой опять-таки не хочется - большой. В то же время понятно, что, например, у строк, которые были вставлены, поменяются идентификаторы (в каждой таблице есть identity-поле). Т.е хочется вернуть назад на клиента результат обработки дифграммы на сервере и вмёрджить его в тот датасет, который уже имеется на клиенте на момент нажатия на кнопку Сохранить.

Как лучше вмёрдживать :)?
В) сначала сделать клиентсокму датасету RejectChanges, потом Merge ответа с 2)
Г) сначала сделать клиентсокму датасету AcceptChanges, потом Merge ответа с 2)
Д) ничего не делать с клиентсикм датасетом, потом Merge ответа с 2)

Может, есть вообще другие варианты? (Энтитис фреймворк не предлагать, использование датасетов "предопределено свыше")

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

Где-то в степи,

Да. Можно сказать и так. Что Вы предлагаете вместо датасета? На всякий случай, дотнет везде второй.

Да, сегмент очень маленький. Т.е. имеется хранилище документов, которое в БД имеет реляционную структуру, аналогичную структуре датасета. Документов десятки миллионов. Один отдельный из них загружается юзером на редактирование в виде датасета.

Где-то в степи1 открывается приложение происходит синхронизация.

Нет. Я не храню на клиенте все миллионы документов. Он выбирает один конкретный на редактирование, и вот только тогда данные загружаются к нему.

Где-то в степиalex_iva1,
я ничего не предлагаю, просто писать свою синхронизацию, или воспользоваться готовой
алгоритм простой.

Если можно, поподробнее - о какой синхронизации идёт речь.

Датасет можно описать в стандартных понятих примерно так:
- одна запись из таблицы Orders
-- к ней все записи из таблицы OrderItems
--- к ним все записи из таблицы OrderItemDetails
-- к ней все записи из таблицы, скажем, OrderClients :)
-- к ней все записи из таблицы, скажем, OrderAdditionalDocumentRefs :)
и т.д.

Таблиц около 30, т.к. документ на самом деле имеет достаточно сложную структуру.

Где-то в степиalex_iva1,
синхронизация по времени обновлении записи
если одна запись.
можно сделать ее объектный мап, передать этот объект клиенту, а потом вернуть его на сервер, а там трансформировать в sql.

Какие преимущества даёт объектный мап (который тоже нужно сериализировать) против датасета, который легко сериализируется в xml и десериализируется обратно?

Где-то в степиalex_iva1,
то что она тянет с собой десятки таблиц ( уж шибко нормализовано) не беда, вы же их не собиратель править на клиенте?
редактироваться может (вообще говоря - зависит от прав пользователя, но это уже другая песня) любая информация в любой из таблиц