Cómo diseñar aplicaciones de escritorio empresariales para Windows 8

Creo que entiendo las expectativas del desarrollo de aplicaciones de consumo para Windows 8. Cree una nueva interfaz de usuario basada en Metro sobre WinRT, impleméntela en su cliente a través del Marketplace y todos ganarán. Parece bastante simple. Lamentablemente, no estoy en ese negocio.

Trabajo en aplicaciones internas de línea de negocio para una gran empresa. Actualmente utilizamos tecnologías .NET como WPF y Silverlight para crear interfaces de usuario ricas que se puedan implementar fácilmente a nuestros usuarios a través de la web o ClickOnce. Las aplicaciones pueden soportar WinXP y Win7 sin demasiado dolor de cabeza, y nuestros desarrolladores pueden usar XAML, que es una tecnología de interfaz de usuario muy sólida.

Parece que WPF y Silverlight tienen futuros cuestionables en este momento, por lo que es un poco preocupante seguir invirtiendo en ellos. Pero una interfaz de usuario de Metro no parece apropiada para aplicaciones empresariales, y la API WinRT es bastante limitante con respecto a las cosas "típicas" que las aplicaciones empresariales deben hacer.

¿Cómo debería diseñar mis aplicaciones basadas en XAML, que actualmente se están implementando en WinXP y Win7, para que sean compatibles y evolucionables en Win8?

Para los fines de esta pregunta, suponga que las características proporcionadas por HTML5 en la parte superior de ASP.NET no son adecuadas para las aplicaciones que estoy buscando crear. Entiendo que puedo usar HTML5 para algunas aplicaciones, pero estoy tratando de averiguar qué debo hacer cuando eso no es suficiente.

Editar # 1: Esto es en respuesta al comentario de @Emmad Kareem. Estoy de acuerdo en que Silverlight / WPF son viables a corto plazo (2-5 años). Sin embargo, las aplicaciones que producimos tienen una vida útil potencialmente muy larga (más de 10-20 años). Por lo tanto, la supervivencia a largo plazo de una tecnología determinada es una preocupación para nosotros. Además, nos preocupa que sea cada vez más difícil encontrar desarrolladores interesados ​​en el desarrollo de Silverlight / WPF si la comunidad considera que esas tecnologías están "muertas". Solo quiero entender mis opciones y tomar una decisión con los ojos abiertos.

Cómo aprendí a dejar de preocuparme y amar la pila de MS

Todavía puede ejecutar aplicaciones VB6 en Windows 8 . La retrocompatibilidad para bien o para mal siempre ha sido una tendencia en el ecosistema de la EM. No debe preocuparse por la supervivencia de tecnologías como WPF / Silveright, e incluso las formas ganadoras para el caso.

Por otro lado, debe aceptar que para un proyecto a largo plazo, nunca tendrá la última tecnología más moderna.

De hecho, las preguntas que debe hacerse sobre la elección de una tecnología son:

• ¿Está mi equipo lo suficientemente cómodo con esa tecnología para ser productivo?
• ¿Mi equipo está feliz de usar esa tecnología?
• ¿Puedo reclutar personas para esa tecnología?

Esa es la combinación de las respuestas a estas preguntas que deberían guiar su elección, y no las tendencias forjadas principalmente por razones de marketing.

Para obtener más información sobre esta temática de la tecnología en constante cambio, debe leer "Fire And Motion" de Joel Spolsky :

Las compañías que tropiezan son las que pasan demasiado tiempo leyendo hojas de té para descubrir la dirección futura de Microsoft. Las personas se preocupan por .NET y deciden reescribir toda su arquitectura para .NET porque piensan que tienen que hacerlo. Microsoft te está disparando, y solo cubre fuego para que puedan avanzar y tú no, porque así es como se juega el juego, Bubby. ¿Vas a apoyar a Granizo? ¿JABÓN? RDF? ¿Lo estás apoyando porque tus clientes lo necesitan o porque alguien te está disparando y sientes que tienes que responder? Los equipos de ventas de las grandes compañías entienden el fuego encubierto.

Y eso fue escrito hace casi diez años.

Arquitectura y tecnologias

La arquitectura y las tecnologías son dos cosas y opciones diferentes que hacer:

• Tu puedes hacer MVC con winforms .
• Tu puedes hacer MVVM con WPF / Silverlight .
• Tu puedes hacer MVC con ASP.NET .
• Tu puedes hacer lo que quiera, incluyendo MVC y MVVM, con WINRT hasta donde sabemos .
• Puedes ir funcional con F # .Por qué no ? Hay dominios donde tendría sentido.
• Puede mezclarlos todos, para tener diferentes puntos de entrada a un sistema común, y luego burlarse porque se vuelve demasiado complicado , etc.

Puede utilizar servicios, recursos, controles de terceros, ORM, etc. con todas estas tecnologías, y quizás, o quizás no, con las siguientes.

Puede torcer y doblar MVC de muchas maneras con todas esas tecnologías: ¿vinculante o no? código detrás de la vista o no? Controlador o no? ViewModel cada vez o solo cuando sea necesario? Hay muchas maneras de implementar un patrón de diseño, incluso dentro del alcance de una tecnología específica.

Sería irrealista forzarlo a uno de ellos sin un conocimiento avanzado de su proyecto y equipo. Solo se basaría en preferencias personales y terminaría en un enfrentamiento de "mi tecnología es mejor que la tuya".

Lo único que se puede sugerir honesta y objetivamente es usar las mejores prácticas que puede aplicar para crear una arquitectura que resistirá el paso del tiempo, y tal vez, realmente tal vez sea portátil o reutilizado al menos en partes con una tecnología futura desconocida . Y esa capacidad de actualización / portabilidad ni siquiera debería ser el objetivo principal de su arquitectura.

El objetivo principal de su arquitectura y tecnología elegida es entregar un producto a su jefe / cliente que cumpla con sus requisitos realistas.

MVC (y su hermano menor MVVM) demostró ser cada vez más una base para una arquitectura robusta desde 1979 en el campo de los idiomas OOP y más allá. Pero elegir qué tecnología específica debe usarse en un proyecto de 10 años debe seguir siendo su decisión.

Una cosa que abordaré en mi libro sobre MVVM es cómo aprovechar el patrón para crear una aplicación central reutilizable. Debería crear una IU nativa para las diversas plataformas a las que se dirige (ya sea web, silverlight, teléfono, WPF o WinRT). Pero en su mayor parte, puede encapsular la lógica que impulsa esa interfaz de usuario detrás de un modelo de vista.

Todos los servicios a los que acceda deben estar detrás de una interfaz (patrón de fachada) que sea más o menos portátil entre plataformas. La interfaz debe correlacionarse con la API de su cliente en el frente y traducirse a la API del servicio envuelto en la parte posterior.

Esta estrategia le ayuda a crear un marco central sólido que solo requiere una nueva interfaz de usuario que se superponga en capas. Piénselo como si su Modelo de vista fuera los músculos, sus servicios forman el esqueleto (y los órganos). WPF / Silverlight / WinRT forman la piel.

De hecho, una cosa que señalo muy temprano en mi libro es que MVVM no es tan nuevo como parece. Dolphin Smalltalk tenía un patrón similar al que llamaron MMVC (las dos M eran Modelo de aplicación y Modelo de dominio). El ViewModel que usamos hoy es solo una combinación del Modelo de Aplicación y el Controlador de MMVC. De hecho, muchos desarrolladores están descubriendo que a veces separar el ViewModel en sus dos componentes tiene sentido (el controlador se usa para la navegación y orquestación de múltiples máquinas virtuales para que la máquina virtual pueda permanecer felizmente inconsciente de otros componentes).

Dices que XAML es sólido pero luego dices que WPF tiene un futuro cuestionable. A menos que me falte algo, WPF usa XAML y no veo que los dos estén separados. ¿Hay alguna noticia que me falte acerca de que WPF posiblemente esté usando alguna otra tecnología base, o sobre que Microsoft posiblemente esté considerando construir otra nueva forma de construir interfaces de usuario? Fuera de eso, dudo que WPF vaya a algún lado, pero no sería la primera vez que MS ha obsoleto las cargas de nuestro código ...

Si necesita una aplicación de interfaz de usuario rica y HTML5 no es suficiente, y su organización está comprometida con el sistema operativo Windows, creo que WPF es la mejor opción, ya que es la última / mejor en este momento, ciertamente sobre las formas de ganar ...

Mi opinión sobre esto es que no debe centrarse demasiado en los detalles de implementación de sus aplicaciones. Si observa una imagen más grande, puede aislar sus dependencias tecnológicas. Al aislar la dependencia de, por ejemplo, xaml / wpf / silverlight, se asegura de que puede reemplazar el componente / tecnología ui con una tecnología de próxima generación y, por lo tanto, garantiza la continuidad incluso en 20 años. Esto también ayudará a desacoplar los componentes de su sistema y también al impacto de tener que realizar dicho reemplazo. (En esto supongo que para proporcionar continuidad está bien jugar con una solución para ponerla en marcha en una plataforma de próxima generación)

Otra forma de proporcionar aislamiento de estas dependencias tecnológicas es habilitar la virtualización. Si crea sus aplicaciones de tal manera que pueda ejecutarlas en una máquina virtual, ¡podrá hacerlo dentro de 20 años!