//
//"public void WriteXml(string, XmlWriteMode);"
//
//в качестве функции-члена "public" (только "private")
//-----------------------------------------------------------------------
void writeDataSetToFile(System.Data.DataSet ds, string filename, System.Data.XmlWriteMode xmlWriteMode) {
//Создать объект XmlWriter для записи наших XML-данных
System.Xml.XmlWriter xmlWriter;
xmlWriter = new System.Xml.XmlTextWriter(filename, System.Text.Encoding.Default);
//ПРИМЕЧАНИЕ: Эта перегруженная версия не является общедоступной (public)!
//ds.WriteXml(filename, xmlWriteMode);
//Вместо этого используем следующую функцию:
ds.WriteXml(xmlWriter, xmlWriteMode);
xmlWriter.Close(); //Важно закрыть файл!
}
Сериализация объектов ADO.NET DataSet с помощью пользовательского кодаКак ранее уже обсуждалось, объекты ADO.NET DataSet обладают встроенной поддержкой сохранения содержимого в виде XML-файлов. В то же время, этот XML-формат не является произвольным и должен соответствовать определенной схеме XML, предназначенной специально для использования с объектами ADO.NET DataSet. Если вашему приложению необходимо выполнять запись или считывание информации с использованием другой схемы XML или любого другого формата, то для этого вы должны сами написать код соответствующей пользовательской логики. Модель, основанная на использовании объектов DataSet, обладает достаточной гибкостью для того, чтобы обеспечить поддержку сохранения данных в любом желаемом виде. Поскольку объекты ADO.NET DataSet поддерживают в памяти простую базу данных, не зависящую от формата хранения, вы можете сохранить этот объект в любом формате (например, в пользовательском формате XML, двоичном, простом текстовом), который отвечает вашим потребностям. Следует лишь отметить, что прежде чем взваливать на себя дополнительную работу по проектированию, необходимо убедиться в том, что для этого имеются серьезные основания.
Если вы пишете пользовательский код десериализации для заполнения данными объекта DataSet, то код вашего приложения должен программным путем построить таблицы, столбцы и определения отношений, а затем заполнить таблицы импортируемыми данными. Аналогичным образом, при пользовательском сохранении объекта DataSet логика вашего приложения должна обеспечить итерирование по всем таблицам и сохранение данных с использованием любого желаемого механизма. Для чтения и записи данных с использованием нескольких различных источников можно привлечь гибридную модель; например, объект DataSet может автоматически заполняться данными при помощи объекта SQLDataAdapter, подключенного к базе данных SQL, а впоследствии эти данные могут быть сериализованы с применением пользовательского формата, локального для устройства. Объектам ADO.NET DataSet безразлично, каким именно образом данные были в них помещены и откуда они поступили.
Работа с нетипизированными объектами DataSetВ .NET Framework для настольных компьютеров и серверов предлагается концепция "типизированных объектов DataSet". Типизированный объект DataSet — это строго типизированный набор интерфейсных классов, реализованных посредством механизма наследования поверх объектов DataSet, DataTable и других объектов данных ADO.NET. Такие унаследованные классы обеспечивают доступ к базовым таблицам и строкам объектов DataSet с использованием строго типизированных членов класса, имена которых совпадают с именами обрабатываемых таблиц и столбцов. Например, вместо того чтобы осуществлять поиск столбцов по именам в соответствии с поздним связыванием (например, myDataRow["CustomerFirstName"]) или требовать использования индексов столбцов (myDataRow[2]), разработчик может использовать раннее связывание свойства (myDataRow.CustomerFirstName). Именно такое связывание на стадии проектирования и есть то, что делает объект DataSet "типизированным". Исходный код для типизированных классов DataSet автоматически генерируется средой времени проектирования Visual Studio .NET.
НА ЗАМЕТКУ
Важно отметить, что строго типизированные объекты DataSet ничуть не эффективнее нетипизированных объектов DataSet. Часто ошибочно полагают иное, поскольку раннее связывание интуитивно представляется более эффективным. Однако раннее связывание типизированных объектов DataSet просто перекладывается на основные нетипизированные объекты DataSet. Типизированные классы DataSet не работают быстрее, их просто легче использовать. Строго типизированные интерфейсные классы позволяют использовать во время проектирования такие возможности, как автоматическое завершение ввода операторов, что облегчает разработку программных кодов на основе объектов DataSet. Они также обеспечивают возможность выявления некоторых видов синтаксических ошибок на стадии проектирования, а не на стадии выполнения. Ничего сверх этого в плане производительности они не дают.