web-services - son - que es una aplicacion metro y en que sistema operativo se utiliza
¿Cómo debe conectarse una aplicación Metro de Windows 8 a una base de datos central? (2)
Parece que otros hacen preguntas similares en los foros de desarrolladores de Microsoft .
Esto es lo que he encontrado:
... No puede tener directamente un SQL db incrustado en su aplicación o usar algo 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, por supuesto, podría conectarse de esa manera. Existen otros métodos ligeros 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 está de acuerdo :
Puede usar HttpClient para descargar casi cualquier cosa de 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 advierte :
... Tenga en cuenta que, aunque impresionante, el proyecto SQLWinRT en codeplex es un contenedor para comunicarse con el motor SQLite clásico ... que utiliza API que no pasarían la validación de la tienda actualmente.
Generic Object Storage Helper para WinRT y WinRTFile Based Database parecen ser prometedores.
Pero Daniel Stolt plantea algunos puntos buenos :
Es increíble que haya un buen soporte para construir clientes OData y otros clientes REST, pero esto solo aborda el escenario 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, lo cual es genial, por supuesto. Pero obligar a cada desarrollador de aplicaciones a construir su propio DBMS además del almacenamiento local de archivos simplemente no lo reducirá, especialmente con todo el System.Data eliminado del perfil. Si el almacenamiento de archivos local fuera suficiente para la mayoría de las aplicaciones de dispositivos, entonces cosas como SQLCE ya no tendrían ningún propósito. Y SQLCE claramente tiene un propósito, y ha jugado un papel muy importante para las aplicaciones de dispositivos ocasionalmente conectadas durante mucho tiempo. También existe una necesidad tremenda de sincronización con una base de datos del lado del servidor como SQL Azure, principalmente para poder roaming de datos entre dispositivos. Sí, existe 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 30 KB si la memoria sirve). Simplemente es insuficiente para todos, excepto para las necesidades más simples de datos de itinerancia. Nuevamente, obligar a cada desarrollador de aplicaciones a diseñar e implementar su propia solución de sincronización es muy malo. Puedes hacer mucho mejor para habilitar a los desarrolladores.
Muchas personas están decepcionadas de que el espacio de nombres System.Data no sea compatible con WinRT.
Ni siquiera tengo palabras para esto. Esto es asombroso Deje de lado por el momento en que quieran obligarlo a abstraerse al middleware para la conectividad de la base de datos. No estoy de acuerdo, pero casi puedo entender una razón fundamental para eso. Incluso puedo ver caminos para desarrollar así.
Pero no System.Data .... en absoluto? ¿Comprendes lo que nos has hecho?
Lo que System.Data puede hacer, aparte de solo tener proveedores para Sql, OleDb y otros proveedores personalizados como Oracle, es proporcionar una rica abstracción de conjuntos de datos XML que le permiten construir muy rápidamente una arquitectura Orientada a Servicios orientada a los datos.
Por ejemplo, puedo crear fácilmente un servicio web usando SOAP o WCF que devuelve DataSets o DataTables, y luego los consumo de forma fácil y directa. Ser capaz de hacer esto permite una construcción muy rápida de arquitecturas de n niveles, incluso sin conexiones directas de datos 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 allí, y servir estructuras, y usar Linq para hacer cualquier clasificación, filtrado, etc. que quieras hacer ... pero termina siendo el doble de trabajo, y hace que el código se reutilice mucho más duro Y significa que el uso de nuestra arquitectura orientada a servicios existente es imposible (sin una gran revisión).
La retirada de System.Data es tan importante para los desarrolladores como la pérdida del objeto Printer en VB6 a vb.net 1.0. 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 como para considerar seriamente incluir las clases System.Data de Mono como parte de cualquier aplicación que cree (que obviamente tendría que ser de código abierto).
¿Cómo debe conectarse una aplicación Metro de Windows 8 a una base de datos central?
- He leído sobre el almacenamiento local, pero no he leído nada sobre la conexión a una base de datos central.
- Obviamente, esta decisión de diseño arquitectónico debe ser compatible con el escenario desconectado.
- Los servicios web de WCF parecen tener sentido.
- Pero incluso si tienen sentido, ¿deberíamos realmente crear métodos separados para todas las operaciones de lectura / escritura?
- ¿O son los servicios WCF de OData el camino a seguir?
- Parece que la arquitectura del software de la tableta debería poder tomar prestado mucho de la arquitectura del software del teléfono inteligente (pero soy nuevo en ambas).
- ¿Microsoft hizo alguna recomendación en sus muestras de aplicaciones ?
Creo que esta es otra de esas preguntas "depende" ...
El primer y más obvio problema es que depende en gran medida del contexto en el que se ejecuta la aplicación si, para tomar el primer caso "Obviamente ... soporte ... desconectado" es realmente cierto - si la aplicación es una aplicación corporativa interna entonces muy posiblemente no en ese caso no db == no funciona.
En segundo lugar, podría mirar (hmm, erupción ... uno supone que podría mirar, esto podría ser una mala suposición) en la sincronización de la base de datos entre una base de datos SQL local y la base de datos remota, y así sucesivamente.
Dando un paso atrás ... sí, tienes toda la razón, mira que es lo mismo que el teléfono o la luz plateada (aunque no sé si todavía hay soporte de RIA), pero la cuestión es que en este punto es muy Es difícil ser preceptivo porque, dada una plataforma de propósito general, uno puede escribir aplicaciones para todo tipo de propósitos.
No es una respuesta muy útil realmente, sino un comienzo.
Después de leer la respuesta de @Jim G parece que probablemente debería retirar la mía?