Разработка модели данных

Пример использования базы данных на устройстве и управления пользовательскими данными

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

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

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

Мы вполне можем обойтись оптимизированным решением, используя низкоуровневые возможности класса SQL СЕ DataReader ( System.Data.SglServerCe.SqlCeDataReader ) для выполнения запросов к локальной базе данных SQL СЕ нашего устройства. В результате запросов наше приложение будет получать однонаправленный курсор, указывающий на данные, которые отвечают критерию запроса. Далее эти данные можно загрузить в память и сохранить в пользовательском формате, специально подобранном таким образом, чтобы обеспечить наиболее эффективную работу со словарем. В интересах простоты и быстродействия соответствующие объекты будут размещаться в массивах. Тем самым будет достигнута существенная экономия времени и памяти по сравнению с общим подходом, основанным на использовании объектов DataSet, поскольку мы размещаем в памяти лишь те объекты, которые действительно будут использоваться в нашем приложении.

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

1. Содержимое базы данных формируется тем же приложением, которое загружает данные из базы данных. Если бы во время проектирования нам были известны все данные, которые потребуются приложению во время выполнения, то и потребность во внешней базе данных была бы небольшой; приложению достаточно заполнить структуры данных в памяти непосредственно в коде и отказаться от накладных расходов, с которыми сопряжена поддержка любой базы данных. В реальной версии данного приложения мы создали бы и заполнили данными базу данных, используя один из трех механизмов:
   • а) загрузка в устройство файла уже наполненной базы данных, которую мы предварительно создали;
   • б) синхронизация базы данных SQL СЕ с серверным вариантом SQL-сервера; и
   • в) выполнение и завершение единственного приложения без сохранения данных созданной и наполненной им базы данных.
2. В память загружаются сразу все данные. Как выше уже отмечалось, словарь для нашего приложения может иметь очень большие размеры. Если бы наша база включала 20 ООО слов, то, вероятно, мы не захотели бы считывать в память все эти слова одновременно. Пользователь от этого ничего не выигрывает, поскольку в любой момент времени он одновременно работает только с небольшим набором из нескольких слов. Мы бы просто выбрали какой-то разумный предел, ограничивающий количество слов, которое наше приложение загружает в каждый момент времени; далее приложение может периодически обновлять встроенный в память кэш новыми словами. Например, мы хотим удерживать в словаре, хранящемся в памяти, не более 500 слов из полной базы данных словаря, насчитывающей 20 ООО слов, из которых в любой момент времени только от 1 до 40 слов должны быть загружены в память. Было бы легко обновить код, осуществляющий считывание слов таким образом, чтобы для каждого слова, которое встречалось, вероятность загрузки составляла 1 /40. Возможны и другие стратегии минимизации количества слов, хранимых в памяти, такие как группирование слов в родственные наборы, загружаемые целиком (например, простые слова, слова повышенной трудности, особо трудные слова). В любом случае мы хотим, чтобы наше мобильное приложение располагало системой управления памятью, которая гарантировала бы, что в любой момент времени в память загружается лишь ограниченное количество слов, так что независимо от того, какой размер имеет база данных, приложение нормально функционирует вполне предсказуемым образом.

Различные способы хранения долговременных данных

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

Хранение данных в виде XML-файлов на устройстве

• Преимущества. Текстовые файлы можно отлично использовать для хранения средних объемов долговременных данных. XML-файлы обеспечивают достижение разумного баланса между пользовательскими и структурными форматами и являются шагом вперед по сравнению с обычными текстовыми файлами. XML-файлы могут легко передаваться между настольными компьютерами, серверами и устройствами и без особого труда интерпретироваться различными приложениями. Учитывая простоту и гибкость XML-файлов, найти для них конкурента очень трудно.
• Недостатки. Текстовые файлы характеризуются увеличенными размерами, но размеры XML-файлов еще больше. Если ваше мобильное приложение работает с множеством данных, эффективное хранение которых необходимо организовать, то XML-файлы для этого не годятся. Кроме того, XML-файлы представляют собой форматированный текст, их содержимое можно легко прочитать и они не обеспечивают защиту данных; по этой причине следует избегать их использования для хранения критически важной информации, если только вы не располагаете надежным механизмом шифрования файлов

Хранение данных в базах данных SOL СЕ на устройствах

• Преимущества. Наличие процессора базы данных на устройстве открывает очень широкие возможности. Встроенные базы данных обеспечивают приложению возможность локального хранения, управления и запроса больших объемов информации. Базы данных SQL СЕ могут защищаться паролями и поэтому обеспе чивают безопасность хранения критически важной информации. Между базами данных SQL СЕ и серверными базами данных SQL можно устанавливать партнерские отношения, что обеспечивает широкие возможности их синхронизации между собой. Для приложений, которым приходится иметь дело с множеством данных, нуждающихся в локальном управлении, этот выбор, вероятно, является наилучшим.
• Недостатки. Самый большой недостаток использования встроенных баз данных состоит в необходимости проверки того, установлен ли процессор базы данных на вашем целевом устройстве. Сама база данных SQL СЕ занимает значительный объем памяти устройства (1-3 Мбайт) и обычно должна устанавливаться на нем, так как нередко она не является частью образа устройства в ПЗУ. Из-за требований к объему памяти не все классы устройств поддерживают размещение процессора базы данных SQL СЕ. Например, в настоящее время размещение SQL СЕ поддерживается Pocket PC, но не поддерживается смартфонами. Кроме занимаемого объема памяти, играют роль и требования синхронизации. Перемещение данных, хранящихся в локальной базе данных устройства, на другой компьютер потребует от вас написания кода соответствующей логики; для перемещения данных между устройствами вам может понадобиться упаковка данных в виде ADO.NET DataSet или привлечение пользовательского формата данных.

Хранение данных в базах данных SQL вне устройства (на сервере)

• Преимущества. Использование для хранения данных и обращения к ним базы данных, расположенной на сервере, является эффективным способом доступа к почти неограниченным объемам данных.
• Недостатки. Для получения данных с сервера или обновления данных на сервере необходимо установить соединение. Если ваше мобильное приложение использует внешнюю базу данных в качестве основного источника данных, планируйте написание пользовательской логики для временного локального сохранения данных в случае разрыва соединения; нет ничего хуже, чем потерять данные в результате сбоя связи при попытке выполнить их обновление на сервере. Мобильным устройствам все время приходится сталкиваться с сетевыми сбоями, и ваше мобильное приложение должно уметь справляться с такими трудностями, возникающими при работе в реальных условиях.

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

Доступ к данным, хранящимся вне устройств, посредством Web-служб

• Преимущества. Web-службы все чаще используются в качестве оболочек доступа к коммерческим источникам данных. Доступ к информации, хранящейся в базах данных, может обеспечиваться через Web-службы без предоставления непосредственного доступа к самим базам данных. Обычно Web-службы работают посредством сетевых протоколов HTTP или HTTPS; как правило, брандмауэры ведут себя дружественно по отношению к этим протоколам. Если сеть уже поддерживает выходной сервер, то создать Web-службу, размещенную на этом сервере, как правило, относительно просто.

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

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

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