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

14

Creo que entiendo las expectativas del desarrollo de aplicaciones para el consumidor para Windows 8. Cree una nueva interfaz de usuario basada en Metro sobre WinRT, desplácela a su cliente a través del Mercado y todos ganarán. Parece bastante simple. Desafortunadamente, no estoy en ese negocio.

Trabajo en aplicaciones internas de línea de negocios para una gran empresa. Actualmente utilizamos tecnologías .NET como WPF y Silverlight para crear UI ricas que se puedan implementar fácilmente a nuestros usuarios a través de la web o ClickOnce. Las aplicaciones pueden admitir 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 adecuada para las aplicaciones empresariales, y la API de WinRT es bastante limitada en lo que respecta a las cosas "típicas" que deben hacer las aplicaciones empresariales.

¿Cómo debo diseñar mis aplicaciones basadas en XAML, que actualmente se implementan en WinXP y Win7, para que sean compatibles y evolucionen en Win8?

Supongamos que, a los efectos de esta pregunta, las características que proporciona HTML5 sobre ASP.NET no son adecuadas para las aplicaciones que busco 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 en el corto plazo (2-5 años). Sin embargo, las aplicaciones que producimos tienen vidas potencialmente muy largas (10-20 años o más). Entonces, la supervivencia a largo plazo para una tecnología determinada es una preocupación para nosotros. Además, nos preocupa que sea cada vez más difícil encontrar desarrolladores que estén interesados en el desarrollo de Silverlight / WPF si esas tecnologías son consideradas "muertas" por la comunidad. Solo quiero entender mis opciones y tomar una decisión con los ojos abiertos.

    
pregunta RationalGeek 19.12.2011 - 14:41

4 respuestas

14

Cómo aprendí a dejar de preocuparme y amar el MS Stack

Aún puede ejecutar aplicaciones VB6 en Windows 8 . La compatibilidad retroactiva de buena o mala siempre ha sido una tendencia en el ecosistema de MS. No debe preocuparse por la supervivencia de tecnologías como WPF / Silveright, e incluso las formas de ganar para esa materia.

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

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

  • ¿Mi equipo está 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 llevar a su elección, y no las tendencias forjadas principalmente por razones de marketing.

Para obtener más información sobre esta temática de tecnología siempre cambiante, debe leer "Fire And Motion" Por Joel Spolsky :

  

Las empresas que tropiezan son las que pasan demasiado tiempo leyendo   Hojas de té para averiguar la dirección futura de Microsoft. La gente consigue   preocupado por .NET y decide reescribir toda su arquitectura para   .NET porque piensan que tienen que hacerlo. Microsoft te está disparando,   y es solo cubrir fuego para que puedan avanzar y tú no puedas,   Porque así es como se juega el juego, Bubby. Vas a   apoyo Hailstorm? ¿JABÓN? RDF? ¿Lo estás apoyando porque tu   los clientes lo necesitan, o porque alguien te está disparando y te sientes   como tienes que responder? Los equipos de ventas de las grandes empresas.   Comprender la tapa de fuego.

Y eso fue escrito hace casi diez años.

Arquitectura y tecnologías

La arquitectura y las tecnologías son dos cosas y elecciones separadas para hacer:

Puede usar servicios, recursos, controles de terceros, ORM, etc. con todas estas tecnologías, y tal vez, o tal vez no, con las siguientes.

Puedes 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 es necesario? Hay muchas formas de implementar un patrón de diseño, incluso dentro del alcance de una tecnología específica.

Eso sería irrealista para obligarte a uno de ellos sin un conocimiento avanzado de tu proyecto y equipo. Solo se basaría en las preferencias personales y terminaría en un showdown "Mi tecnología es mejor que la tuya".

Lo único que se puede sugerir de manera honesta y objetiva es usar las mejores prácticas que puede aplicar para crear una arquitectura que resista la prueba del tiempo, y tal vez, en realidad, sea portátil o reutilizado al menos en partes con un Futura tecnología desconocida. Y esa capacidad de actualización / portabilidad no debería ser el objetivo principal de su arquitectura.

El propósito 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 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.

    
respondido por el Matthieu 19.12.2011 - 15:21
1

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 distintas plataformas a las que apunta (ya sea web, silverlight, phone, WPF o WinRT). Pero en su mayor parte, puede encapsular la lógica que impulsa esa IU detrás de un ViewModel.

Cualquier servicio al que tenga acceso debe estar envuelto detrás de una interfaz (Patrón de fachada) que sea más o menos portátil entre plataformas. La interfaz debe asignarse a la API de su cliente en el frente y traducirse a la API del servicio envuelto en la parte posterior.

Esta estrategia lo ayuda a crear un marco de núcleo sólido que solo requiere una nueva interfaz de usuario para ser superpuesta. Piense en ello como su modelo de vista, siendo los músculos, sus servicios hacen que el esqueleto (y los órganos). WPF / Silverlight / WinRT forman la piel.

De hecho, una cosa que señalé 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 es lógico separar el ViewModel en sus dos componentes (el controlador se usa para la navegación y para la organización de múltiples máquinas virtuales, de modo que la máquina virtual puede ignorar alegremente otros componentes).

    
respondido por el Michael Brown 19.12.2011 - 15:58
0

Dice que XAML es sólido pero luego dice que WPF tiene un futuro cuestionable. A menos que me esté perdiendo algo, WPF usa XAML y no veo que los dos estén separados. ¿Hay alguna noticia que me esté perdiendo sobre la posibilidad de que WPF utilice alguna otra tecnología básica, o sobre la posibilidad de que Microsoft considere la posibilidad de crear una nueva manera de crear interfaces de usuario para otra ? Fuera de eso, dudo que WPF se vaya a algún lado, pero no sería la primera vez que MS ha obsoleto los botes de nuestro código ...

Si necesita una aplicación de interfaz de usuario enriquecida y HTML5 no la eliminará, y su organización está comprometida con el sistema operativo Windows, creo que WPF es la mejor opción, ya que es la mejor / la mejor en este momento, sin duda alguna sobre las plataformas de Windows .

    
respondido por el minnow 19.12.2011 - 15:33
0

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

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

    
respondido por el Carlo Kuip 19.12.2011 - 20:48