Parece que otros están haciendo preguntas similares en el Microsoft Developer Forums.
Esto es lo que he encontrado:
According to Tim Heuer:
... No se puede tener directamente una base de datos de SQL incorporado en su aplicación o uso algo así como ADO.NET. Esto es más una infraestructura asincrónica/de servicios . Entonces, si sus datos fueron expuestos a través de servicios, entonces del curso podría conectarse de esa manera. Existen otros métodos livianos de que puede usar para el almacenamiento local y también para cosas como el espacio de nombres Windows.Storage (que es similar al Almacenamiento aislado en .NET).
Morten Nielsen agrees:
Puede utilizar HttpClient descargar casi cualquier cosa desde la web. ¿Por qué no configura su servicio WCF para devolver datos como JSON, y usa DataContractJsonSerializer para deserializar los resultados?
Además, Tim Heuer cautions:
... Tenga en cuenta que, si bien impresionante, el proyecto SQLWinRT en CodePlex es un envoltorio para comunicarse con el motor SQLite clásico ... que utiliza las API que se no pasar la validación de la tienda actualmente.
Generic Object Storage Helper for WinRT y WinRTFile Based Database parecen tener alguna promesa.
Pero Daniel Stolt raises some good points:
Es impresionante que hay un buen apoyo para la construcción de los clientes OData y otros clientes REST - pero esto sólo se ocupa de la situación en línea. La parte "estructurada" de Windows.Storage es un modelo muy limitado, esencialmente limitado a pares de nombre/valor, insuficiente para todos excepto para los escenarios más básicos . Sí, hay almacenamiento de archivos local, que es genial , por supuesto. Pero forzar a cada desarrollador de aplicaciones a construir su propio DBMS encima del almacenamiento local de archivos simplemente no lo cortará, especialmente con todo el System.Data eliminado del perfil. Si el almacenamiento de archivos local era suficiente para la mayoría de las aplicaciones de dispositivos, entonces cosas como SQLCE no tendrían ningún propósito hoy. Y SQLCE claramente tiene un propósito , y ha jugado un papel muy importante para las aplicaciones de dispositivo conectadas de vez en cuando durante mucho tiempo. También existe una gran necesidad de para la sincronización con una base de datos del lado del servidor como SQL Azure, principalmente para poder roaming de datos entre dispositivos. Sí, hay el modelo de almacenamiento itinerante en WinRT, pero comparte las mismas limitaciones de almacenamiento local mencionadas anteriormente, y además de esto, tiene una capacidad muy limitada (actualmente de 30 KB si la memoria está disponible) . Es simplemente insuficiente para todas las necesidades de datos de roaming más simples. De nuevo, forzando a cada desarrollador de aplicaciones a diseñar e implementar su propia solución de sincronización es muy malo. Puede hacer mucho mejor para habilitar a los desarrolladores de .
Muchas personas están decepcionados de que el espacio de nombres System.Data no se admite en WinRT.
Richard Bethell said:
Yo ni siquiera tengo palabras para esto. Esto es asombrosoDeje de lado por en el momento en que lo obliguen a abstraer al middleware para la conectividad de la base de datos - No estoy de acuerdo, pero casi puedo entender una razón de ser para eso. Incluso puedo ver caminos para desarrollar así.
Pero no System.Data .... en absoluto? ¿Incluso comprende lo que ha hecho para nosotros?
Lo System.Data puede hacer, fuera de sólo tener proveedores para SQL, OleDb y otros proveedores personalizados, como Oracle, es proporcionar una rica abstracción de bases de datos XML que le permiten construir rápidamente una de datos orientada orientada a servicios Arquitectura.
Por ejemplo, puedo crear fácilmente un servicio web usando SOAP o WCF que devuelve DataSets o DataTables, y luego consume esos objetos fácilmente y directamente. Ser capaz de hacer esto permite una construcción muy rápida de las arquitecturas n-tier , incluso sin conexiones de datos directas disponibles.
Sin System.Data, y el poder de DataViews, DataTables, etc. esto se vuelve mucho más difícil. Claro que puedes crear estructuras personalizadas, poner datos en allí, y servir estructuras, y usar Linq para hacer cualquier clasificación, filtrar, etc. que quieras hacer ... pero termina siendo el doble del trabajo , y hace que la reutilización de código sea mucho más difícil. Y significa el uso de nuestros arquitectura orientada a servicios existentes es imposible (sin un gran revisión.)
La retirada de System.Data es tan grande una cosa para los desarrolladores para hacer frente con como la pérdida del objeto Printer en VB6 para vb.net 1.0 fue. Lo que es más difícil de entender en este caso es por qué es necesario - volver a habilitarlo en el perfil de Metro no puede ser una dificultad técnica del producto, ¿o sí?
Es lo suficientemente valioso que consideraría seriamente incluyendo clases System.Data de Mono como parte de cualquier aplicación (creo que, obviamente tiene que ser de código abierto.)
tiene cualquier cambio ocurrido desde que ha publicado su pregunta y respuesta? ¿Podría sugerir (s) referencia (s) de cualquier cambio significativo? Gracias. – NoChance