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

15

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.

RationalGeek
fuente
Tengo que correr a una reunión, pero tengo una respuesta para usted :)
Michael Brown
2
¿Por qué cambiarías el WPF / Silverlight con el que ya estás familiarizado? Su declaración "WPF y Silverlight tienen futuros cuestionables", bueno, Microsoft no dejará caer esta tecnología durante la noche. Si seguirá creciendo no es una preocupación real si tiene suficiente funcionalidad hoy. En resumen, debe tener una razón técnica sólida para considerar una arquitectura totalmente nueva. Algunos de los sustos se deben a que las personas pierden su experiencia a otra tecnología más. No puedo culparlos.
NoChance
3
¿Desea que una sola pila de tecnología dure más de 10 años? ¿Por qué no enfocarse en una buena arquitectura y principios de diseño para permitir que su sistema evolucione con el tiempo para usar las tecnologías apropiadas? Eche un vistazo a Visual Studio: existe desde 1995 y ha evolucionado con el tiempo. Por ejemplo, Visual Studio 2010 agregó una actualización importante de la interfaz de usuario que incluyó el uso de WPF y otros cambios arquitectónicos para agregar puntos de extensibilidad. No puede controlar qué tecnologías o paradigmas serán grandes el próximo año, y mucho menos en el marco de tiempo que está viendo.
Thomas Owens
55
¿Qué te hace pensar que ejecutarás Windows en 20 años?
JonnyBoats
1
@ JonnyBoats: porque lo estábamos ejecutando 20 años ? ¿O porque su principal competidor se basa en un sistema aún más antiguo ? No hay forma de predecir la caída o la supervivencia de una tecnología específica.
Matthieu

Respuestas:

15

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:

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.

Matthieu
fuente
Estoy totalmente de acuerdo con esta respuesta. Nunca se puede estar seguro. Pero hay múltiples tecnologías que podrían satisfacer las preguntas que usted plantea, y todavía tengo que elegir entre ellas.
RationalGeek
@jkohlhepp: se agregó un párrafo sobre arquitectura y tecnologías. Creo que es imposible recomendar objetivamente una tecnología sobre la otra o una arquitectura sobre la otra.
Matthieu
¿Su postura es que no hay una base objetiva para comparar arquitecturas / tecnologías? ¿No es ese el propósito de la disciplina de la arquitectura? Estoy de acuerdo en que todo se trata de los requisitos de mi jefe. Uno de esos requisitos es la longevidad máxima por el costo más barato, de ahí esta pregunta.
RationalGeek
@jkohlhepp: la disciplina de arquitectura de software de mi humilde opinión es como la medicina. Obtiene experiencia para encontrar el tratamiento adecuado para una enfermedad específica. Hay diferentes maneras de hacerlo en algún momento, y puede ser peligroso tratar de curar a todos de la misma manera con el mismo tratamiento. Si tiene un equipo efectivo de programadores experimentados en WPF y Silverlight, quédese con él y mantenga su arquitectura existente. Si tiene que cambiarlo, no lo cambie solo porque hay nuevas formas de hacer las cosas, que ya está haciendo de manera eficiente, comercializado por Microsoft.
Matthieu
Puedo subir a bordo con ese Matthieu. Gracias por las respuestas reflexivas.
RationalGeek
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 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).

Michael Brown
fuente
Estoy totalmente de acuerdo en aplicar diferentes partes de la aplicación. Y también estoy totalmente de acuerdo en que debe hacer que su interfaz de usuario sea lo más tonta posible porque las tecnologías de interfaz de usuario tienden a agitarse un poco. Pero, incluso después de crear esas capas, aún tiene que adivinar qué tecnologías serán mejores / más baratas a largo plazo.
RationalGeek
Si tuviera que adivinar ... mientras HTML5 es la nueva moda en estos días, Microsoft continuará admitiendo XAML porque lo controlan. Aprendieron su lección de Java (originalmente estaban planeando usar Java como el principal lenguaje .NET cuando Sun se enfrentó a ellos), el soporte HTML es para llegar. Desarrollar su aplicación con principios sólidos (IU declarativa respaldada por un rico modelo de objetos portátiles) debería ayudarlo a capear la tormenta. Incluso tengo ejemplos de cómo hacer MVVM en Javascript (echa un vistazo a knockout js).
Michael Brown
0

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 ...

pececillo
fuente
La dirección que escuché de MS ha insinuado que WPF no tiene mucho futuro a largo plazo. Pero no han anunciado nada. Espero que lo pongan en un "modo de mantenimiento" como lo hicieron con LINQ To SQL.
RationalGeek
WPF está depravado en Windows 8 (en el sentido de que te devuelven abruptamente al "modo de escritorio" y de la experiencia inmersiva de Metro). Sin embargo, puede crear aplicaciones de Metro con XAML. Son tecnologías completamente separadas.
Domenic
Erm, no, no está en desuso porque el escritorio sigue siendo una parte clave de la experiencia. En cuanto a "tecnologías completamente separadas", ¿en serio? Seguramente mucho más cerca de las variaciones sobre un tema como ya es el caso con WPF vs Silverlight (en oposición al uso de XAML para el flujo de trabajo, por ejemplo)
Murph
0

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!

Carlo Kuip
fuente
Desde cierto sentido puedo entender esta perspectiva. Sin embargo, yo no necesito elegir una tecnología de interfaz de usuario en algún momento, y según esta elección se requerirá el reemplazo / actualización tarde o temprano. Me gustaría hacer una elección que resulte en la máxima longevidad.
RationalGeek
Según el sitio del ciclo de vida, Silverlight5 será compatible hasta octubre de 2021 support.microsoft.com/lifecycle/?p1=16278 Entonces, pase lo que pase con la hoja de ruta, sigue siendo una opción sólida.
Carlo Kuip