.net - WPF/Silverlight VS WinRT

windows-runtime

Question

Nunca construí una aplicación (ni HelloWorld) en WinRT, y tengo muchas sospechas.

Mi pregunta es si hay características en WPF / Silverlight que no existen en WinRT (excluyendo las características que se implementan de manera diferente por diseño)?

Y estos aspectos son los más importantes para mí y son el núcleo de mi pregunta y, en consecuencia, la decisión de comenzar a usar WinRT o esperar a que se implementen:

• ¿Marco de la entidad?
• WCF RIA?
• Soporte MVVM (Prisma) ???
• Varios kits de herramientas (Silverlight / WPF toolkit), que proporcionan controles adicionales como DatePicker etc.

No me queda claro si WinRT se enfoca completamente en .NET o cómo funciona.

Además, ¿es WinRT una aplicación solo para clientes (como WPF) o puede ejecutarse en un cliente remoto mientras está sentado en un servidor (como Silverlight)?

Otro: ¿Qué pasa con la compatibilidad con versiones anteriores, si desarrollo una aplicación WinRT, alguna vez podrá trabajar en Win XP?

De todos modos, no entiendo por qué MVVM no está integrado en línea y tiene un soporte IDE perfecto como MVC. pero eso es sólo una nota al margen. No puedo usar XAML sin MVVM, cualquier aplicación que sea un poco más grande que hola mundo es más fácil de hacer con MVVM.

Actualizar después de la answer

Como comenté la respuesta, me gusta el diseño de WinRT, pero la pregunta sigue sin resolverse hasta que conozca las tecnologías específicas mencionadas anteriormente (EF, WCF-RIA + Validation, MVVM, SDKs y Toolkits). Y, obviamente, no voy a comenzar a vender aplicaciones WinRT ni a profundizar en ellas hasta que tenga al menos los técnicos mencionados anteriormente.

Conclusión, como uno de los que más de su trabajo son las aplicaciones de LOB, después de revisar un poco, HTML5 + JS está lejos de ser una alternativa a SL. Así que para concluir, me limito a SL y sigo recomendándolo a mis clientes. SL toma el menor tiempo de desarrollo y está libre de errores. Javascript es un lenguaje sucio propenso a errores, sin patrón y sin nuez, comparado con C #.

Una vez que los kits de herramientas EF + RIA + Prism + sean totalmente compatibles con WinRT, consideraré llevar mis aplicaciones LOB al metro.

Answer 1

Tenga en cuenta que WinRT se dirige a las aplicaciones de estilo Metro de Windows 8 NO a las aplicaciones de escritorio convencionales (Windows 7) desarrolladas con WPF o Winforms. Las aplicaciones de estilo Metro se distribuirán SOLAMENTE a través de la Tienda Windows. Microsoft cobra un 30% por las aplicaciones de la Tienda Windows. Los desarrolladores obtienen el 70%. Este es el mismo ''impuesto'' que cobra Apple. Olvídate de Silverlight para la versión estilo Metro de Internet Explorer. NO admite complementos. Recuerda que Silverlight ES un plugin. La versión de escritorio de Internet Explorer admite complementos, por lo tanto, Silverlight.

Answer 2

WinRT es básicamente una colección de objetos COM que envuelven un montón de API de Win32, expuestos como ensamblajes compatibles con CLI.

Microsoft modificó su compilador de C ++ para consumir y generar metadatos de ECMA 335 (es decir, CLI) en lugar de los formatos de archivo MIDL o lib más tradicionales y (en gran medida) C ++ / COM solo. Microsoft también modificó su motor Chakra Javascript para consumir y emitir metadatos CLI.

Esto significa que cuando se dirige a código WinRT, Javascript y C ++, junto con los lenguajes .NET, por supuesto, pueden consumir ensamblajes compatibles con CLI (es decir, .NET) y pueden emitir ensamblados compatibles con CLI (es decir, .NET).

Entonces, uno puede escribir código WinRT en C ++, cualquier lenguaje .NET (es decir, C #, VB.NET, F #, Iron *, etc.) y en Javascript.

La API de WinRT será MUY familiar para usted si alguna vez ha escrito algún código .NET. El equipo de Windows realmente buscó la ayuda y orientación del equipo de diseño de .NET Framework al diseñar WinRT, por lo que se han aplicado las mismas pautas de diseño que han guiado a todo el equipo de .NET framework y la mayor parte de la comunidad .NET durante los últimos 11 años. la API de WinRT.

WinRT es, francamente, hermoso :)

El principal impacto de WinRT es que reemplaza el archivo, la red y las clases de IO de System.IO con API similares pero que SOLO admiten IO asíncrono. Esto significa que no podrá escribir aplicaciones que bloqueen subprocesos mientras esperan que regresen las llamadas al sistema de archivos o sistemas externos a través de la red, a menos que tome pasos explícitos para hacerlo.

Esto es una buena cosa.

Afortunadamente, las nuevas características de async / await de C # v5 y VB.NET v.next, junto con el soporte específico para C ++ significan que no tienes que ir y cambiar fundamentalmente la forma en que escribes el código en este nuevo mundo asíncrono. es necesario agregar una palabra clave "asíncrona" a las firmas de métodos que llaman a las API asíncronas y luego usar la palabra clave ''esperar'' prefijando cada llamada a la API asíncrona.

Le recomiendo encarecidamente que vea la sesión de Anders Hejlsberg, que debería dejar esto muy claro. Mientras estás allí, también te animo a que veas varias de las otras // sesiones BUILD, especialmente la charla de Harry Pierson sobre el uso de WinRT con C # & VB.NET y la sesión de Mads en Async Made Simple en C # y VB .

También te recomiendo que eches un vistazo al diagrama mejorado de la arquitectura de la plataforma Win8 / WinRT que escribí hace unas semanas, lo que debería aclarar un poco las cosas.

En cuanto a .NET en sí, como articulo en mi publicación anterior, .NET no está "desapareciendo". Si bien algunas de las API de .NET estarán prohibidas en las aplicaciones de WinRT (es decir, el bloqueo de las API de IO), la mayoría de las API de las que depende permanecerán y serán completamente accesibles.

Respecto a Silverlight: Silverlight es un complemento del navegador. Es un subconjunto modificado de WPF y ofrece algunas características muy potentes y atractivas. Tanto es así, de hecho, que el motor Silverlight XAML se trasladó al equipo central de Windows y se usa para la mayoría de la representación de la interfaz de usuario de Metro en Windows8, ¡incluso por el propio sistema operativo!

El resultado final es que la mayoría de su código de Silverlight se ejecutará sin apenas modificaciones , aparte de cambiar algunos espacios de nombres "utilizando".

Hay una tonelada de sesiones enfocadas en XAML de BUILD disponibles para ver aquí .

Con respecto a la compatibilidad con versiones anteriores, el objetivo es:

• Aísle el código que desee usar en WinRT, así como en las aplicaciones de escritorio .NET, Windows Phone, etc. en ensamblajes portátiles siempre que sea posible.
• Código abstracto que debe tomar dependencias específicas de la plataforma y considerar la posibilidad de cargarlos manualmente o usar IoC para componer sus módulos juntos.

Francamente, no creo que sea tarea de Microsoft escribir todos los marcos para cada escenario. Hay varios enfoques / marcos de trabajo de MVVP en el mundo salvaje de varias personas con varios pros y contras. Y si no encuentra uno, cree uno y péguelo en GITHub y hágase famoso;)

Sin embargo, sobre todo, hay poco que te impida descargar y probar Win8 Consumer Preview & Dev11 Beta. Ve por ellos y pruébalos. Creo que los encontrarás muy refrescantes :)

HTH.

Actualización # 1 en respuesta al soporte específico para EF, WCF, etc.:

Puede encontrar el área de superficie de la API de WinRT enumerada aquí con algún detalle . Las principales API de WCF se enumeran aquí .

Sin embargo, tenga en cuenta que Microsoft recomienda encarecidamente que no se utilicen coomms de red para comunicarse entre las aplicaciones de Metro y otras aplicaciones de Metro o aplicaciones / servicios de escritorio en la misma máquina. Lea esta pregunta SO y la respuesta de Kate Gregory: ella se enlaza a un video en el que se discute este escenario en detalle.

Si desea comunicarse con servicios de red externos, tiene una amplia variedad de opciones que incluyen WCF, sockets, etc.

Con respecto a RIA: Microsoft actualmente está diciendo que si desea obtener datos, deberá obtenerlos a través de un servicio en lugar de hacerlo directamente desde una base de datos. No hay ADO.NET para Metro y la recomendación es que salgan a la superficie datos a través de OData, JSON, XML / HTTP, etc. Los datos como servicio son en gran medida un escenario de RIA, por lo que espero que RIA tenga un buen soporte para las aplicaciones de Metro. Aquí hay una sesión de CONSTRUCCIÓN sobre este tema que puede arrojar más luz.

Solo usted puede saber si sus escenarios específicos son compatibles con WinRT. Creo que lo mejor sería descargar los bits y comenzar a explorar.

Actualización 2 siguiendo la guía y guía actualizadas de P&P: P&P ha publicado recientemente una nueva guía y guía para la creación de aplicaciones LOB de "tienda" / "modernas" de Windows RT / Windows 8.

Esta guía incluye actualizaciones de Prism / Kona y también incluye EntLib6 y Unity3 (IoC) . Animo a cualquier persona interesada en este espacio a estudiar los materiales publicados y las aplicaciones de referencia.