Как приложение Windows 8 Metro должно подключаться к центральной базе данных?
Как приложение Windows 8 Metro должно подключаться к центральной базе данных?
- Я читал о локальном хранилище, но я ничего не читал о подключении к центральной базе данных.
- Очевидно, что это архитектурно-дизайнерское решение должно поддерживать отключенный сценарий.
- Веб-сервисы WCF, кажется, имеют смысл.
- Но даже если они действительно имеют смысл, должны ли мы действительно создавать отдельные методы для всех операций чтения / записи?
- Или сервис OData WCF - это путь?
- Кажется, что архитектура программного обеспечения для планшета должна быть в состоянии многое позаимствовать из архитектуры программного обеспечения для смартфона (но я новичок в обоих случаях).
- Microsoft сделала какие-либо рекомендации в своих примерах приложений?
2 ответа
Похоже, что другие задают подобные вопросы на форумах разработчиков Microsoft.
Вот что я нашел:
... Вы не можете напрямую встроить базу данных SQL в свое приложение или использовать что-то вроде ADO.NET. Это больше асинхронная / сервисная инфраструктура. Так что, если ваши данные были представлены через службы, то, конечно, вы могли бы подключиться таким образом. Существуют и другие легковесные методы, которые можно использовать для локального хранилища, а также с использованием таких вещей, как пространство имен Windows.Storage (аналогично изолированному хранилищу в.NET).
Вы можете использовать HttpClient для загрузки практически всего из Интернета. Почему бы вам не настроить службу WCF для возврата данных в формате JSON и использовать DataContractJsonSerializer для десериализации результатов?
Также Тим Хойер предупреждает:
... Обратите внимание, что, несмотря на то, что проект SQLWinRT в codeplex является отличным средством, он является оболочкой для связи с классическим механизмом SQLite..., который использует API, которые в настоящее время не проходят проверку хранилища.
Хелпер хранилища общих объектов для баз данных на основе WinRT и WinRTFile, похоже, имеет определенные перспективы.
Но Даниэль Штольт поднимает некоторые хорошие моменты:
Удивительно, что есть хорошая поддержка для создания клиентов OData и других клиентов REST - но это касается только сетевого сценария. "Структурированная" часть Windows.Storage - очень ограниченная модель, по существу ограниченная парами имя / значение, недостаточная для всех, кроме самых основных сценариев. Да, есть локальное хранилище файлов, что, конечно, здорово. Но принуждение каждого разработчика приложений к созданию собственной СУБД поверх локального хранилища файлов просто не обрежет это, особенно если удалить все данные System.Data из профиля. Если бы локальное хранилище файлов было достаточно для большинства приложений для устройств, то такие вещи, как SQLCE, сегодня уже не имели бы цели. И у SQLCE явно есть цель, и она очень долго играла очень важную роль для приложений, время от времени подключенных к устройствам. Существует также огромная потребность в синхронизации с базой данных на стороне сервера, такой как SQL Azure, в основном для возможности перемещения данных между устройствами. Да, в WinRT есть модель хранения в роуминге, но она имеет те же ограничения, что и локальное хранилище, упомянутое выше, и, кроме того, имеет очень ограниченную емкость (в настоящее время 30 КБ, если используется память). Это просто недостаточно для всех, кроме самых простых потребностей данных в роуминге. Опять же, принуждать каждого разработчика приложений к разработке и внедрению собственного решения для синхронизации очень плохо. Вы можете сделать намного лучше, чтобы включить разработчиков.
Многие разочарованы тем, что пространство имен System.Data не поддерживается в WinRT.
У меня даже нет слов для этого. Это удивительно. Оставьте в стороне, пока они хотят заставить вас абстрагироваться от промежуточного программного обеспечения для соединения с базой данных - я не согласен, но я могу немного понять обоснование этого. Я даже вижу пути такого развития.
Но нет System.Data.... на всех? Ты хоть понимаешь, что ты с нами сделал?
System.Data может сделать, не имея только поставщиков для Sql, OleDb и других пользовательских поставщиков, таких как Oracle, - предоставить обширную абстракцию наборов данных XML, которая позволяет очень быстро создать ориентированную на данные сервис-ориентированную архитектуру.
Например, я могу легко создать веб-сервис с использованием SOAP или WCF, который возвращает DataSets или DataTables, а затем легко и напрямую использовать эти объекты. Возможность сделать это позволяет очень быстро создавать n-уровневые архитектуры даже при отсутствии прямых подключений к данным.
Без System.Data и возможностей DataViews, DataTables и т. Д. Это становится намного сложнее. Конечно, вы можете создавать собственные структуры, помещать в них данные и обрабатывать структуры, а также использовать Linq для выполнения любых операций сортировки, фильтрации и т. Д., Которые вы хотите выполнить... но это в итоге удваивает работу и делает повторное использование кода намного сложнее. А это значит, что использование нашей существующей сервис-ориентированной архитектуры невозможно (без капитального ремонта).
Вывод System.Data так же важен для разработчиков, как и потеря объекта Printer в VB6 для vb.net 1.0. Что труднее понять в этом случае, так это то, почему это необходимо - его повторное включение в профиле Metro не может быть технической сложностью продукта, не так ли?
Достаточно ценно, что я серьезно рассмотрел бы включение классов System.Data Mono в состав любого приложения, которое я создаю (которое, очевидно, должно быть с открытым исходным кодом).
Я думаю, что это еще один из тех вопросов, "это зависит"...
Первая и наиболее очевидная проблема заключается в том, что она очень сильно зависит от контекста, в котором выполняется приложение, относительно того, действительно ли для первого случая "Очевидно... поддержка... отключена" действительно ли верно - если приложение является Внутреннее корпоративное приложение тогда вполне возможно, что не в этом случае нет д.б.
Во-вторых, вы можете посмотреть (хм, сыпь... можно предположить, что вы можете посмотреть, это может быть неверным предположением) о синхронизации базы данных между локальной базой данных SQL и удаленной базой данных и так далее, и так далее.
Делая шаг назад... да - вы абсолютно правы, смотрите на это так же, как на телефон или silverlight (хотя я не знаю, есть ли еще поддержка RIA), - но на данный момент все очень Трудно быть предписывающим, потому что, учитывая платформу общего назначения, можно писать приложения для любых целей.
Не очень полезный ответ на самом деле - но начало.
Прочитав ответ @Jim G, кажется, что я должен забрать мой?