Тэкс... После небольшой паузы продолжим наши "игры". Для впервые читающих — объяснения всему происходящему тут

Автор: Smarty
Дата: 29.12.06

.
Итак — продолжим про данные ADO.NET-а, т.е. про ДатаТейблы. В предыдущем

Автор: Smarty
Дата: 04.01.07

выпуске мы увидели как грамотно их наполнить содержимым. Теперь — как это содержимое грамотно сохранить на диск/передать товарищу по И-нету(и вообще по проводам).

===[Smarty Q&A]=Выпуск 2=Begin===

Q. Мне нужно сериализовать DataSet(аналогично DataTable) для последующей передачи по проводам(аналогично — для сохранения на диск). В каком формате это лучше/правильнее делать?
A. В FW 1.x выбора не было — DataSet сериализовался в XML-text и только в него. В FW 2.0 появилась вторая сериализация — бинарная. Выбор между ними происходит через новое св-во DataSet-а(в DataTable так же есть одноименное) — RemotingFormat(типа перечисления SerializationFormat). Собственно возможных значений у данного св-ва всего 2: XML/Binary. Причем по умолчанию применяется первое. Почему так? Ответ — что бы приложения из предыдущего FW будучи запущенными под FW 2.0 не "падали" пытаясь XML-но десериализовать бинарно сериализованные объекты. Хорош ли этот дефолтный выбор для нас, девелоперов, работающих только под FW 2.0 или для тех, кого вопрос обратной совместимости не беспокоит? Ответ — в 99% этот выбор плох. Бинарная сериализация имеет громадные преимущества перед XML-ной. Отметим хотя бы в разы меньший объем информации передающийся по проводам, и в разы же более быстрый процесс как сериализации, так и десериализации. Некоторые источники утверждают, что просто смена значения этого св-ва с дефолтного на Binary повышает производительность особо "тяжелых"(в смысле их загрузки различными данными) распределенных приложений в... 80(!!) раз. Вывод — думаем о сериализации — меняем значение этого св-ва. А что же за 1% когда следует все же остаться на XML-сериализации? А это такие нетипичные сценарии, когда вся таблица, подлежащая отправке по сети попадает в категорию "два столбца — одна строка". Т.е. когда объем информации в таблице исчисляется буквально десятками байт — выбор за дефолтовой сериализацией. У бинари-сериализации очень "большой" заголовок со служебной информацией, хотя понятно, что для любой мало-мальски реальной таблицы этот "большой" заголовок будет каплей в море на фоне объема данных самой таблицы.
Сам код сериализации практически не претерпел изменений и остался элементарен:

....
using System.Runtime.Serialization.Formatters.Binary;
using System.IO;
....
....
dt.Load(sdr); //dt - тот самый DataTable который мы наполнили данные в пред. выпуске(ссылка на этот выпуск выше)
dt.RemotingFormat = SerializationFormat.Binary; //не забываем, что теперь такое возможно!
BinaryFormatter formatter = new BinaryFormatter();
FileStream fs = new FileStream("c:\\Serialized.bin", FileMode.Create);
formatter.Serialize(fs, dt);
fs.Close();

===[Smarty Q&A]=Выпуск 2=End===

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

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

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

L> от бинарной сериализации мне пришлось — во время сериализации значеий

в смысле, "от бинарной сериализации мне пришлось отказаться"

Здравствуйте, Smarty.
Читаю, Вашу серию QA. И желание увидеть кроме раздела "как можно сделать 'правильно'" еще и раздел "как сделать 'чтобы работало максимально быстро'" с соотвествующими результатами тестов усиливаеться.
Надеюсь, также, что для следующих постов Вы выберете более глубокие темы.
Желаю удачи!

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

S>FileStream fs = new FileStream("c:\\Serialized.bin", FileMode.Create);
S>formatter.Serialize(fs, dt);
S>fs.Close();

думаю лучше будет так:

using (FileStream fs = new FileStream("c:\\Serialized.bin", FileMode.Create))
{
    formatter.Serialize(fs, dt);
}

не забываем тогда уж и о Guidance Explorer

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

L>Дифирамбы бинарной сериализации можно выпевать долго, но у сего способа есть по меньшей мере один злобный баг, вследствие которого от бинарной сериализации мне пришлось — во время сериализации значеий типа DateTime все DBNull-значения превращаются в... DateTime.MinValue.

Не только. Есть еще одна проблема с DateTime — https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93670

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

AVK>Не только. Есть еще одна проблема с DateTime — https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93670

Про проблему с DateTime+bin сериализация я знал. Но рассказывая о любой "фенечке", особенно новой(относительно), неизбежно пришлось бы употреблять фразы "...маленький косячок..", "...не мешало бы пройтись еще разок напильником..." и т.д. Но это все объём заметки и время, потраченое читателем. Я же стремлюсь, что бы на чтение каждого Q&A выпуска уходило 2-4 мин. максимум. Поэтому неизбежно приходится жертвовать деталями. Хотя, понятно, когда дело дойдет до дела эти "детали" могут нивелировать весь полезный информационный объём заметки. Ну тут уж на определенные жертвы идти приходится...

P.S. Кстати — в FeedBack-е в MS(по ссылке выше) есть пункт

4) Serialize DataSet using SoapFormatter

А почему не просто ...using BinaryFormatter? В этом есть какой умысел? Ведь мы же

3) Set RemotingFormat property of DataSet to SerializationFormat.Binary

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

S>Надеюсь, также, что для следующих постов Вы выберете более глубокие темы.
Безусловно. Жаль только понятие "глубины" у junior- и guru-developer совершенно разное. А заранее знать кто будет читать определенный выпуск невозможно.

S>Желаю удачи!
Спасибо — буду стараться!

Здравствуйте, Mono.m, Вы писали:

MM>думаю лучше будет так:

Принимается. Понятно, что сути не меняет, но что более правильно — не сомненно.

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

Ryf>не забываем тогда уж и о Guidance Explorer

Отличная тулза с большим(как мне кажется) будущим. Спасибо за линк!

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


S>Про проблему с DateTime+bin сериализация я знал. Но рассказывая о любой "фенечке", особенно новой(относительно), неизбежно пришлось бы употреблять фразы "...маленький косячок..",

Нифига себе маленький. Я не представляю себе типичное приложение, использующее DataSet, но не использующее DateTime. Вывод — бинарная сериализация DataSet в промышленных приложениях ныне unusable. И предложение твое вредное.