.net - línea - ¿Cuál es el enfoque adecuado para la interfaz de usuario moderna para las aplicaciones de escritorio de Windows?

modern ui descargar

Question

Tengo una aplicación existente con un extenso modelo de C ++ que me gustaría conectar a una agradable y moderna interfaz de usuario de Windows 7 u 8. La interfaz de usuario (antigua) actual para nuestra aplicación se desarrolló a principios de la era de Windows XP / 95/98 utilizando API Win32 pura. Nuestro código actualmente se está compilando / enlazando a través de Visual Studio 2010.

Parece que hay muchos "estándares" de API de desarrollo diferentes en Windows: Win32, MFC, ATL, COM y .NET. En los últimos 14 años, mis ingenieros casi remolcaron la línea de Microsoft: en 2001, fue "MFC está muerto, debemos pasar a ATL" (no lo hicimos). Entonces ".NET REEMPLAZARÁ MFC" (no parece tenerlo).

Así que ahora estamos listos para volcar nuestro antiguo código de UI. Sería bueno trabajar con un conjunto de estándares que sean sólidos y eficientes, pero también uno con el que podamos crear UI rápidamente. Dejando de lado QT (en el que he leído un montón de ventajas y desventajas bien argumentadas aquí en stackoverflow):

1) ¿El enfoque moderno de desarrollo de interfaz de usuario para Windows 7 y 8 sería usar MFC o .NET?

2) Para un enfoque .NET (asumiendo que hay razones sólidas para elegir .NET) ¿podríamos usar nuestro código modelo C ++ SIN MANEJAR con una aplicación .NET?

3) ¿Es esencial hacer desarrollo en Visual Studio 2012, incluso si nuestra aplicación no se diseñaría inicialmente para una apariencia de Metro?

4) ¿Hay algún otro kit de herramientas de Microsoft que deba considerarse para el desarrollo de aplicaciones de escritorio?

Stephen

Answer 1

1. Podrías ir con cualquiera de los enfoques. Sin embargo, .NET es mucho más común para el diseño de la interfaz de usuario y tiene muchas ventajas (en términos de desarrollo más rápido) si necesita una interfaz de usuario flexible.

2. Sí. C ++ / CLI funciona bien para unir el código nativo con la interfaz de usuario .NET.

3. No. Puedes hacer esto en VS2010. Dicho esto, VS 2012 tiene muchas ventajas, especialmente cuando se trabaja con C ++. La actualización probablemente sea beneficiosa.

4. Yo miraría a WPF . La nueva interfaz de usuario de Windows 8 podría ser interesante, pero podría ser difícil de usar con tu código base anterior. Además, no funcionará en sistemas operativos más antiguos. En mi experiencia, WPF es la mejor opción que mejora actualmente (hubo muchas mejoras en .NET 4.5) que permite mezclar una base de código existente con nuevas tecnologías de interfaz de usuario.

Answer 2

Una solución realmente fácil de decir sería portar todo el código de C ++ a C # o C ++ / CLI de .NET y luego interconectarlo con WPF. Esto puede ser complicado, pero, disfruta de la facilidad de codificación completamente en .NET (3.5 SP1 y Visual Studio 2010 preferible).

También puede interconectar el código existente con .NET para usar WPF a través de COM Interop. COM Interop esencialmente registra un componente .NET como un componente COM en un sistema. Cuando se invoca, el CLR realiza la ejecución del código y la clasificación para que su programa llame (Más información - msdn.microsoft.com/en-us/library/zsfww439(v=vs.80).aspx).

El método final es volcar MFC y llamar directamente a la API de Windows (Win32). La API de Windows puede ser más fácil de usar desde su código que los otros métodos. En la moderna API de Windows, GDI + (interfaz de dispositivo de gráficos) se implementa encima de DirectX (DWM y DXGI) y se puede extender fácilmente a través de COM y es una alternativa bastante viable para WPF y la interfaz de usuario moderna.

Answer 3

Nadie debería crear un nuevo proyecto basado en MFC y Win32. La interfaz de usuario de Windows Mordern y la API unificada son el futuro. No creo que .Net sea la respuesta para todas las aplicaciones, especialmente para proyectos que tienen una gran cantidad de código nativo de C ++. Sabemos que Microsoft está trabajando en la API unificada. Espero que esa sea la respuesta a esta pregunta.

Answer 4

Mire esta respuesta que di en 2011. Argüiría que todavía se mantiene hoy; tal vez incluso más, dado el reciente cambio a C ++ de Microsoft. No estoy seguro de cuánto soporte adicional para win8 hay en MFC, pero si no está cambiando completamente a Metro (lo cual me imagino que no lo hará, si tiene un ''producto'' necesitará soportar Windows anterior por lo menos, ¿qué, 5 años?), no importa demasiado.

Aún no he visto una aplicación .Net / WPF que se sienta tan "sólida" como C ++ (sí, me doy cuenta de que son técnicamente ortogonales, pero en realidad, ¿quién construye .NET UI en C ++?). Entiendo por qué la gente quiere alejarse de MFC; no es que no entiendo sus lados negativos. OMI, ¿a qué se reduce? ¿Cuánto valor le das al desarrollo rápido? Para algunas aplicaciones (línea de negocio, productos con una vida útil corta), el tiempo de comercialización y la velocidad de los cambios es más importante que la ingeniería ''sólida''. Para otros (herramientas profesionales, software de sistemas), la creación de software sólido con una gran experiencia de usuario es más importante. Aún no me han mostrado el software de producción (a diferencia de las ''demos tecnológicas'') que hacen eso en los marcos más ''modernos''; MFC (o quizás debería decir ''win api usado a través de C ++'', pero MFC en ese aspecto tiene suficiente para que los positivos superen a los negativos) las aplicaciones son (todavía) (a menudo) la mejor herramienta para eso. IMO.

Sin embargo, una última cosa a considerar son tus desarrolladores. Si han estado programando MFC por 15 años, probablemente estén programando sus carreras en una esquina. Si insiste en continuar utilizando MFC, puede enajenarlos. Deberá sopesar los riesgos comerciales en comparación con las consideraciones técnicas (de su pregunta deduzco que es propietario de un negocio). No dude en ponerse en contacto conmigo para la discusión de seguimiento si prefiere hacerlo en privado.