Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Ввиду вышесказанного вам уже должно быть ясно, что для чтения и записи XML-данных гораздо лучше использовать библиотечные функции, специально разработанные для этой цели и прошедшие строгое тестирование. Преимущество этих функций заключается в том, что они проектировались, создавались и тестировались группой специалистов, способных с полным знанием дела справиться с задачей создания наиболее быстрого и надежного механизма для работы с XML.
Для работы с XML-документами в .NET Compact Framework предлагается двухуровневый подход:
■ Средства однонаправленного чтения и записи XML-документов. Для максимально быстрого выполнения однонаправленного (forward-only) чтения/записи XML-документов без применения кэширования используются классы XmlReader и XmlWriter. Задачей этих классов является чтение или
■ XML DOM (Document Object Model — объектная модель документов). Класс XmlDocument используется для представления создаваемого в памяти дерева объектов, описывающего XML-документ. XmlDocument и связанные с ним классы представляют объектную модель документов, обеспечивающую легкий доступ к элементам представляемых деревьев XML. Документ считывается только в прямом направлении с использованием обсуждавшегося выше класса XmlReader, на основании чего создается дерево элементов, представляющее XML-документ в памяти. Аналогичным образом, данные из XML-дерева могут быть записаны в поток; для выполнения этой задачи используется класс XmlReader. Возможности класса XmlDocument больше всего подходят тем разработчикам, которые либо имеют дело с XML-документами небольших или средних размеров, либо хотят вносить как можно меньше усложнений при работе с XML-документами
Концептуально соответствующая функциональность концептуально представлена в пространстве имен System.Xml.*.
Библиотеки данных
Данные в современных базах данных хранятся в виде наборов взаимосвязанных таблиц. Для работы с реляционными данными такого рода в NET Framework предлагается объектная модель под названием ADO.NET. Модель ADO.NET предоставляет в распоряжение разработчиков классы, позволяющие управлять в памяти набором связанных между собой реляционных таблиц, а также классы, обеспечивающие различные представления этих данных. О данных, для управления которыми используется модель ADO.NET, говорят, что они находятся в объекте DataSet.
На протяжении последних 10-15 лет компания Microsoft предложила ряд различных библиотек объектов для доступа к данным, каждая из которых улучшала предшествовавшую модель. До появления ориентированной на использование управляемого кода технологии ADO NET применялась технология ADO название которой является аббревиатурой от ActiveX Data Objects (объекты данных ActiveX), и которая предназначалась главным образом для того, чтобы предоставить возможность обращаться к информации, хранящейся в базах данных, разработчикам на Visual Basic. В настоящее время все предыдущие модели (вместе с их многочисленными загадочными трехбуквенными акронимами наподобие DAO, RDO, ADO и номерами различных версий — прошу прощения, если я что-то перепутал!) вытеснены ADO NET.
В то время как предыдущими технологиями доступа к данным, такими как ADO, предлагались объекты RowSet, каждый из которых представлял одиночную таблицу данных с курсором, указывающим на текущую строку, в ADO.NET предлагаются объекты DataSet, представляющие наборы связанных таблиц, хранящихся в памяти вместе с межтабличными ссылками на объекты.
В ADO.NET данные представляются не в виде изолированной таблицы с курсором, обеспечивающим перемещение между строками, а в виде хранящейся в памяти схемы таблиц, навигация между которыми осуществляется с использованием объектно-ориентированных механизмов. В ADO.NET не существует понятия курсора текущей строки, поскольку данные явным образом отделены от любых подключений к базе данных, для которых мог бы потребоваться курсор. Для связывания объектов ADO.NET DataSet с внутренними источниками данных в ADO.NET используются объекты DataReader. Объекты DataReader предоставляют лишь возможность однонаправленного считывания данных из источника данных. Эти объекты используются внутренним образом для заполнения данными объектов ADO.NET DataSet.
При работе с наборами данных DataSet, хранящимися в памяти, разработчики имеют возможность выполнять над ними целый ряд операций,
включая следующие:■ Сохранение внесенных текущих изменении в базах данных. Интерфейс между объектами ADO.NET DataSet и базами данных обеспечивается классом DataAdapter. Классы DataAdapter получают список добавлений, обновлений и удалений, относящийся к DataSet, и применяют соответствующую логику для распространения этих изменений на основную базу данных. Обычно это делается путем выполнения SQL-операторов или вызова хранимых процедур, предназначенных для работы с базой данных.
■ Сохранение данных в виде XML-документа. Объекты DataSet можно сериализовать в документы XML и сохранять в виде файлов с возможностью их последующей повторной загрузки.
■ Пересылка данных другому звену. Поскольку объекты DataSet, включая информацию о внесенных в них изменениях, без труда переводятся в форму постоянно существующих XML-документов, можно легко осуществлять их передачу между различными звеньями вычислительной системы посредством вызовов Web-служб.
■ Локальное использование данных. Объекты DataSet можно использовать как мощную абстракцию для работы с базами данных в памяти. Если эти данные предназначены только для чтения то внесенные в них локальные изменения не распространяются на данные, расположенные на сервере или в долговременном хранилище.
Вынесение полезной отладочной и проектной информации в необязательные компоненты
Управляемый код может содержать большое количество информации, которая может быть полезной для разработчиков при отладке каркасов, компонентов и приложений. В качестве примера подобных данных, привносящих добавленную стоимость, можно привести текстовые описания возможных исключений, которые возникают в процессе выполнения кода. Одно дело, когда сообщения об ошибках выводятся в виде малоинформативных фраз наподобие "Неизвестное исключение" или "Возбуждено исключение System.IO.SomeRandomException", и совершенно другое, когда вы получаете понятное простому смертному сообщение, подробно описывающее суть происшедшего и его наиболее вероятную причину. Информация подобного рода полезна на стадиях тестирования и отладки, но при разработке таких крупных проектов, как NET Compact Framework, для хранения всех строк сообщений об ошибках может потребоваться слишком много места, что в случае мобильных устройств является непозволительной роскошью.
.NET Framework для настольных компьютеров просто включает в себя обширную информацию об исключениях наряду с другими ресурсами. Эта информация доступна не только на английском, но и на многих других основных языках, для которых была выполнена локализация Visual Studio; это означает, что конечные пользователи имеют возможность получать богатую диагностическую информацию на своем родном языке. Чтобы обеспечить доступ к этой информации программным путем, каждое исключение управляемого кода имеет свойство .Message, открывающее программный доступ к соответствующему тексту.
Наличие текстовых строк с богатой отладочной информацией является несомненным преимуществом, однако за это преимущество приходится платить увеличением размера системы. Изначально ясно, что для подробных текстовых описаний требуется выделять много места. Для этого потребуется еще больше места, если предусмотрена локализация описаний. В связи с этим возникает вопрос о возможных проектных ограничениях, поскольку задачи обеспечения компактности системы и предоставления как можно более подробной текстовой информации вступают в конфликт между собой.
В .NET Compact Framework эта проблема решается за счет разбиения указанной информации на отдельные вспомогательные компоненты не входящие в базовый состав NET Compact Framework. Эти вспомогательные компоненты могут устанавливаться поверх .NET Compact Framework в соответствии с необходимостью или желанием. Файл, содержащий эту информацию, имеет название System.SR.dll, а его размер составляет 91 Кбайт. Для других языков локализации предусмотрены дополнительные версии этого файла. Всего в настоящее время существует 10 таких локализованных языковых версий, суммарный размер которых достигает 900 Кбайт, что составляет ощутимую долю общего размера .NET Compact Framework. Таким образом, исключение этих строк из .NET Compact Framework позволяет значительно уменьшить суммарный размер системы.