Visual Studio .NET 2005 и SQL СЕ
В следующей версии SQL СЕ и .NET Compact Framework будет предложено два существенных усовершенствования, касающихся доступа к данным при работе с SQL СЕ.
1. Класс SqlCeResultSet даст разработчикам возможность перемещаться по данным и обновлять их непосредственно в базе данных SQL СЕ. Это упростит создание приложений, которые работают с базами данных вплотную, а не используют высокоуровневые абстракции наподобие объектов ADO.NET DataSet.
2. SQL СЕ будет поддерживать многопользовательский доступ. Это означает, что несколько приложений на одном устройстве смогут одновременно открывать одни и те же базы данных и работать с ними. Благодаря этому устранятся некоторые из описанных выше проблем, связанных с параллельным доступом к базам данных на устройстве.
Даст что-либо введение этих новых функциональных возможностей вам и вашему приложению? Ответ звучит так: "Возможно". Многие разработчики мобильных приложений выбирают в качестве целевых такие устройства, в ПЗУ которых уже содержатся необходимые среды выполнения, поскольку это упрощает развертывание приложения. (Для некоторых устройств такая возможность является единственной, но это уже тема следующей главы.) Если речь идет о таких приложениях, то должно пройти некоторое время, пока не наберется некоторое критическое количество устройств, ПЗУ которых содержат обновленные компоненты. Однако если у вас есть возможность установить обновленную среду выполнения и процессор базы данных, то это стоит сделать хотя бы ради того, чтобы иметь эти средства.
Как и в случае задач повышения производительности, управления памятью и построения пользовательского интерфейса, создание удачной модели данных для мобильного приложения требует одновременно и планомерного подхода, и экспериментирования. Хорошая новость состоит в том, что многое из вашего опыта организации доступа к данным на настольных компьютерах вы сможете использовать при проектировании кода для доступа к данным в мобильных приложениях. Плохой же новостью является то, что вы сможете непосредственно использовать лишь небольшую часть уже имеющегося кода для настольных компьютеров, а для создания замечательных мобильных приложений вам придется учитывать специфику мобильных устройств.
При организации доступа к данным самое важное — это определить, каким образом ваша стратегия доступа к данным будет удовлетворять потребности пользователей при работе в автономном режиме. Реалии таковы, что соединение между вашим мобильным приложением и серверами баз данных будут часто разрываться, иногда по причине того, что "так было задумано", а иногда — из-за сбоев в сети. Работе в условиях периодически разрывающихся соединений специально посвящена следующая глава, но этот момент является ключевым и при проектировании стратегии доступа к данным. Если пользователю требуется немедленный доступ к данным, они должны кэшироваться локально на устройстве.
В зависимости от того, как будет использоваться ваше мобильное приложение, ему может потребоваться соединение с источниками данных посредством самых различных моделей подключения. Некоторые модели подключения, например Wi-Fi, отличаются высокой скоростью передачи данных и небольшой стоимостью, тогда как другие работают медленно и обладают высокой стоимостью. Дополнительные требования к разрабатываемому проекту могут появиться из-за необходимости поддержки соединений через общедоступные или виртуальные частные сети. В процессе проектирования модели доступа к данным для мобильного приложения важно представлять себе, какими могут быть сценарии подключения, и каким образом это может отразиться на ваших потребностях доступа к данным и их синхронизации. Важно продумать, какие данные будут храниться локально на устройстве, как будет организовано хранение этих данных и доступ к ним, и каким образом эти данные будут синхронизироваться с серверами.
В средах программирования доступа к данным часто предлагают многоуровневые подходы для организации работы с данными. Как и при работе с XML-ориентированными средами, существуют низкоуровневые модели однонаправленного доступа к данным, которые не имеют состояния, и построенные поверх них полнофункциональные модели, хранящие очень подробную информацию о своем состоянии. ADO.NET предлагает возможность выбора между этими типами моделей. Как разработчик, вы можете работать либо на высоком уровне абстракции, используя объекты ADO.NET DataSet для управления данными в памяти, либо на низком уровне, используя непосредственно классы DataReader и DataConnection, которые напрямую связываются с базами данных. Как и на заправках, полный сервис — это, разумеется, неплоxo, но за все услуги надо платить; в случае доступа к данным дополнительной платой за использование высокоуровневых служб будет необходимость хранения состояния в памяти, а это, в конечном счете, означает снижение производительности.
Читать дальше