Чтение онлайн

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

Рис. 14.3. Альтернатива использованию объектов ADO.NET DataSet

Модель программирования, основанная на использовании объектов ADO.NET DataSet, предоставляет замечательные возможности для работы с реляционными данными, однако ее применение уместно не в любом контексте. Важно понимать, когда следует использовать ADO.NET для удовлетворения потребностей приложения в доступе к данным, а когда — не следует.

Объекты ADO.NET DataSet следует использовать в тех случаях, когда приложению требуются широкие возможности манипулирования данными в памяти или когда возникает необходимость в использовании сложного реляционного способа прослеживания данных. Поскольку, по существу, ADO.NET поддерживает для вас в памяти небольшую реляционную базу данных, которая отслеживает вносимые изменения, то использование этого протокола предоставляет широкие возможности для автоматического управления набором в высшей степени динамичных данных, а также навигации по связям между отдельными порциями данных. Объекты ADO.NET DataSet оказываются удобными в тех случаях, когда 1) объем данных, с которыми вы должны работать, не слишком велик по сравнению с емкостью памяти мобильного устройства, и 2) данные имеют динамическую природу, что диктует необходимость отслеживания и распространения изменений.

Объекты ADO.NET DataSet обеспечивают обмен данными с долговременным хранилищем. Такой обмен осуществляется одним из трех способов: 1) использование классов DataAdapter, осуществляющих соединение с базами данных посредством объектов подключения к данным, 2) сериализация объектов DataSet в файлы и потоки XML и наоборот, и 3) сериализация посредством пользовательского кода, который считывает данные из объектов DataSet или помещает данные в указанные объекты. Краткие описания каждого из упомянутых способов передачи данных приводятся ниже.

Тип ADO.NET System.Data.Common.DataAdapter — это абстрактный класс, то есть он предоставляет шаблон для порождения других классов DataAdapter, специфических по отношению к базе данных, которые, собственно говоря, и используются. Вместе с .NET Compact Framework поставляются два адаптера данных:

1. SqlDataAdapter. Класс System.Data.SqlClient.SqlDataAdapter используется при работе с базами данных SQL Server, выполняющимися на серверах.

2. SqlCeDataAdapter. Класс System.Data.SqlServerCe.SqlCeDataAdapter используется при работе с базами данных SQL СЕ, выполняющимися на мобильных устройствах.

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

Независимо от выбранного вами типа адаптера данных объекты DataAdapter работают посредством присоединенных к ним объектов Command. В отличие от класса DataAdapter у класса Command нет корневого класса, от которого могли бы быть произведены другие классы Command, специфические по отношению к базам данных; понятие класса Command существует лишь как понятие, которое используется при работе с различными адаптерами данных. Для объектов SqlDataAdapter существуют связанные с ними объекты SqlCommand, для объектов SQL СЕ SqlCeDataAdapter — объекты SqlCeCommand, и так далее. В свою очередь, с объектами Command связываются объекты Connection, которые отображают команды (commands) на конкретный экземпляр той или иной базы данных; например, для выполнения команд при работе через конкретное соединение с базой данных SQL Server объект SqlCommand будет использовать объект SqlConnection. Указанные объекты Command исполняют запросы и другие команды баз данных, которые должны выполняться для извлечения данных из баз данных или помещения их в базы данных, используемые вашим приложением. Объектам Command известно, как осуществлять те или иные действия при работе с той или иной базой данных, когда они выполняют SQL-команды для выборки, обновления, вставки или удаления данных. Так, для выполнения этих команд у класса SQLDataAdapter имеются следующие четыре свойства: SelectCommand, UpdateCommand, InsertCommand и DeleteCommand. Каждое из этих свойств имеет тип SqlCommand. Аналогичным образом, у объекта SqlCeDataAdapter также имеются четыре свойства с теми же именами, но типом этих свойств является SQLCeCommand.

Краткое подведение итогов. Адаптеры данных играют роль посредников при осуществлении связи между объектами ADO.NET DataSet и базами данных. Как правило, для выполнения этих функций адаптеры данных используют объекты Command. Объекты Command являются специфическими по отношению к каждому типу баз данных. В свою очередь, объекты Command обычно ассоциируются с объектами Connection, владеющими соединениями с конкретным сервером. В типичных случаях объект Command является владельцем таких SQL-операторов, как Select * from Customers, а объекты Connection — владельцами логического соединения с базой данных, через которое им передаются эти команды.

При создании .NET-приложений для настольных компьютеров и серверов Visual Studio .NET предлагает инструментальные средства времени проектирования, которые облегчают настройку конфигураций адаптеров данных и ассоциированных с ними классов Command; это значительно упрощает процесс доступа к базам данных. В отличие от этого, для создания и использования адаптера данных в .NET Compact Framework вы должны сами написать код, обеспечивающий конфигурирование объектов DataAdapter и Command для работы с используемыми вами источниками данных. Возможно, в будущем автоматизированные средства будут поддерживать также .NET Compact Framework и объекты DataAdapter и DataCommand для работы с популярными базами данных, но пока что вы можете полагаться только на самих себя. Поскольку предусмотренные для настольных компьютеров и серверов инструментальные средства для работы с базами данных автоматически генерируют исходный код для приложений, часто имеет смысл воспользоваться сгенерированным ими кодом и адаптировать его для выполнения на мобильных устройствах; хотя этот код и будет существенно отличаться от того, что вам нужно, он послужит вам неплохой отправной точкой.

Сохранение содержимого объектов ADO.NET DataSet в виде XML-файлов можно считать вариантом "базы данных для бедных". Данные приложения сохраняются в текстовом файле с использованием формата, который позволяет осуществить последующую повторную загрузку данных в память в виде объекта ADO.NET DataSet. Это аналогично получению объекта DataSet, возвращаемого через запрос Web-службы. В противоположность сохранению данных в базе данных использование текстового XML-файла для хранения данных лишает ваше приложение богатых возможностей транзакций и гарантий целостности данных, предлагаемых современными базами данных. Несмотря на ограниченность этой модели в отношении хранения больших объемов данных и возможности обновления данных посредством механизма транзакций, она может хорошо послужить при хранении данных небольшого объема (например, XML-файлы размером 20 Кбайт) или при перемещении данных на сервер посредством XML-потоков. Сохранение объектов DataSet в виде постоянно существующих XML-файлов можно рассматривать как простой способ упаковки небольших или средних объемов информации о состояния приложения для ее последующего повторного использования.

При записи содержимого объекта DataSet в файл или поток XML важно внимательно изучить опции, предлагаемые перечислением System.Data.XmlWriteMode. Исходя из соображений производительности, при сохранении объектов DataSet в виде постоянно существующих XML-файлов рекомендуется одновременно сохранять XML-схему (то есть использовать System.Data.XmlWriteMode.WriteSchema). Запись схемы данных вместе с самими данными обеспечивает существенное ускорение повторной загрузки XML-данных в объект DataSet; в противном случае схема должна будет динамически определяться во время повторной загрузки данных, а это потребует выполнения дополнительной работы. В листинге 14.2 представлен простой пример сохранения объекта DataSet в XML-файле. В этом примере предоставляется возможность задавать параметр WriteSchema.

Чтобы выполнить пример, дополните код, приведенный в листинге 14.1, кодом из листинга 14.2 и добавьте элемент управления Button, который вызывает функцию writeDataSetToFile.