Программирование мобильных устройств на платформе .NET Compact Framework

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

Базы данных предлагают наивысшую степень организации данных, однако привносят с собой дополнительные накладные расходы, связанные с выполнением процессора базы данных.

Различные уровни абстракции программной модели

Обычно программные модели, предназначенные для работы с сохраненными данными, имеют несколько уровней. Так, для работы с файлами в .NET Compact Framework предлагаются следующие уровни абстракции, перечисленные в порядке их повышения:

■ Двоичные потоки.

■ Текстовые потоки.

■ Объекты однонаправленного чтения и записи XML.

■ Объектная модель документов (DOM) XML.

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

Выбор формата хранения данных и программной модели

Какой формат данных следует использовать для хранения данных — целиком зависит от целей вашего приложения; никакого универсального рецепта здесь не существует. Распространенной ошибкой тех, кто только приступает к разработке программного обеспечения для мобильных устройств, является допущение о том, что, поскольку в этом случае приходится иметь дело с ограниченными ресурсами, следует сразу же переходить на самый низкий уровень абстракции и использовать двоичные файлы наряду с потоковыми операциями файлового ввода-вывода. Иногда необходимость в этом действительно существует, но в большинстве случаев это просто означает выполнение ненужной работы, которая потребует дополнительного тестирования и, вероятно, приведет к худшему решению, не обеспечивающему достаточной гибкости. Общее правило заключается в том, чтобы использовать наивысший уровень абстракции, допустимый с точки зрения размера данных и достигаемой при этом производительности. Было бы неразумно изобретать собственный двоичный формат для данных сравнительно небольшого объема, поскольку при средних запросах памяти лучшего варианта, чем XML, не найти. С XML легко работать, он обеспечивает надежную работу с различными версиями данных и для него существует высокоуровневый API- интерфейс, упрощающий процесс программирования. Точно так же, в случае возникновения действительной необходимости в двоичном формате, например, для хранения больших объемов данных, описывающих изображения, гораздо предпочтительнее воспользоваться уже имеющимися и проверенными на практике форматами, если таковые имеются. Поскольку существует целый ряд хорошо зарекомендовавших себя форматов изображения, изобретение собственного формата будет, как правило, напрасной тратой времени. При любой удобной возможности старайтесь использовать уже существующие компоненты и форматы данных; изобретайте свои собственные форматы лишь в тех случаях, когда вы убеждены, что высокоуровневые подходы не сработают.

Работа с внешними по отношению к устройству ресурсами