Подскажите как это делается в net следующая операция.
Есть сервер приложений, раздающий клиентам сериализованные datatable или dataset

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

Есть там какой-нибудь другой, более удобный механизм для осуществления всего этого?

Более удобных механизмов пока нет :)
Тут целая эмпирическая наука.

Я использую такие принципы:
- в датасеты по возможности грузить минимум данных, используя постраничное пролистывание или некие условия поиска для уменьшения объема возвращаемого сервером набора данных

- если размер датасета не превышает 50-100 кБ, то удобнее перегнать  датасет на сервер и обратно клиенту целиком:

DataSet dsTemp = Server.Save(dsSource);
dsSource.Clear();
dsSource.Merge(dsTemp);
dsSource.AcceptChanges();

, что при условии наличия 100-мегабитной сети гарантирует нам приемлемые производительность и время отклика (не менее 50 запросов в секунду).

- если размер датасета превышает озвученную цифру, то получаю измененный набор при помощи DataSet.GetChanges() и отправляю на сервер только изменения без получения изменений от сервера (синхронизации).

MyDataSet dsChanges = (MyDataSet)dsSource.GetChanges();
Server.Save(dsChanges);

- в ряде случаев нужно работать с большим датасетом, гарантируя синхронность в том случае, если с таблицей одновременно работают несколько пользователей (например, какой-нить прейскурант на 300-1000 записей). В этом случае приемлемым вариантом может оказаться такой: на сервер отправить только изменения,  из базы данных запросить датасет целиком, отправить клиенту, произвести слияние (Mergе) клиентского и серверного датасетов.

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

Я одного не понимаю: зачем гонять от сервера к клиенту и обратно датасеты?
Чем это лучше прямых запросов к SQL-серверу?

> Чем это лучше прямых запросов к SQL-серверу?
Долго объяснять. Деплой легче, секурность выше, устойчивость к сетевым сбоям, офф-лайн режим прикрутить можно, и кэширование справочников на клиенте в оперативке или на диске удобно делать, ну и прочие адекватные преимущества трехзвенок радуют, если до абсурда не доводить.

В моем случае это просто требование такое.
Это плагин к офису.
На клиенте может не быть ни клиента MSSQL ни оледв провайдера.
Было реализовано примерно как у Ломброзо, (DataSet.GetChanges())
но хотелось "волшебства".
:)

> DiamondShark ©   (27.12.06 18:32) [2]
> Я одного не понимаю: зачем гонять от сервера к клиенту и
> обратно датасеты?
> Чем это лучше прямых запросов к SQL-серверу?


Гонять датасэты между клиентом и сервером удобно. На самом деле "гоняются" почти что чистые наборы данных. При этом еще не надо отдельно передавать метаданные или как-то иначе организовывать структурирование данных.
Кроме того, ADO.NET имеет большое количество удобных методов для работы с данными. Например, объединение датасэтов, выделение только изменившихся записей, выборки из НД и многое другое.
Ничего общего с прямыми запросами клиента к SQL-серверу не имеет. Клиент просто принимает набор данных, созданный на сервере приложения в наиболее удобном для клиента виде - "упакованным" в объект "датасэт".

>  На самом деле "гоняются" почти что чистые наборы данных.

Это "почти" может достигать разницы в 3 раза для xml-сериализованных датасетов и 1.5 раз для binary-сериализованных по сравнению с native-протоколом SQL-сервера.


> При этом еще не надо отдельно передавать метаданные или
> как-то иначе организовывать структурирование данных.

Как это не надо? То, что метаданные размазаны по всем данным, а не собраны в отдельный пакет, не означает, что их нет.
И при xml-сериализации, и при binary-сериализации метаданные присутствуют.
Да ещё и с дикой избыточностью.


> Кроме того, ADO.NET имеет большое количество удобных методов
> для работы с данными. Например, объединение датасэтов, выделение
> только изменившихся записей, выборки из НД и многое другое.

Это всё замечательно именно для клиентской обработки данных.


> Клиент просто принимает набор данных, созданный на сервере
> приложения в наиболее удобном для клиента виде - "упакованным"
> в объект "датасэт".

Тут абстракции играют с вами злую шутку.
Объекты никогда не передаются и не получаются. Объекты всегда существуют только в локальной памяти. Передаются только так или иначе отформатированные данные.
Полезно иногда стряхивать очарование абстракций и смотреть на то, что стоит за ними.
Связка adapter-dataset позволяет воссоздать на клиенте "наиболее удобный вид" объекта датасет ничуть не хуже (а, принимая во внимане описанные в [1] танцы с бубном, -- даже лучше).
"А если результат одинаков, зачем платить больше?" (ц)