Похоже, что другие задают подобные вопросы на форумах разработчиков Microsoft .
Вот что я нашел:
По словам Тима Хойера:
... Вы не можете напрямую встроить базу данных SQL в свое приложение или использовать что-то вроде ADO.NET.Это больше асинхронная / сервисная инфраструктура.Так что, если ваши данные были представлены через службы, то, конечно, вы могли бы подключиться таким образом.Существуют и другие легковесные методы, которые можно использовать для локального хранения, используя такие вещи, как пространство имен Windows.Storage (аналогичное изолированному хранилищу в .NET).
Мортен Нильсенсогласен :
Вы можете использовать HttpClient для загрузки практически всего из Интернета.Почему бы вам не настроить службу WCF для возврата данных в формате JSON и использовать DataContractJsonSerializer для десериализации результатов?
Кроме того, Tim Heuer предостерегает :
... Обратите внимание, что, хотя проект 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 как часть любого приложения, которое я создаю (что, очевидно,
должен быть с открытым исходным кодом.)