tutorial - ¿Prueba futura de una aplicación de interfaz de usuario grande: MFC con el paquete de características de 2008 o C#y Winforms?
wpf vs windows forms (6)
Mi compañía ha desarrollado un producto de larga data utilizando MFC en Visual C ++ como el estándar de facto para el desarrollo de la interfaz de usuario. Nuestra base de código contiene MUCHO código heredado / arcaico que debe mantenerse operativo. Parte de este código es más antiguo que yo (originalmente escrito a fines de los 70) y algunos miembros de nuestro equipo todavía están en Visual Studio 6.
Sin embargo, afortunadamente, se ha llegado a la conclusión interna de que nuestro producto se ve algo anticuado en comparación con el de nuestros competidores, y que hay que hacer algo.
Actualmente estoy trabajando en una nueva área de la interfaz de usuario que está bastante separada del resto del producto. Por lo tanto, me han dado la oportunidad de probar pilas de tecnología ''nuevas'' como una especie de campo de pruebas antes de que comience el largo proceso de movimiento sobre el resto de la IU.
He estado usando C # con Windows Forms y .NET Framework durante un tiempo en mi tiempo libre y lo disfruto, pero estoy algo preocupado por los dolores de cabeza causados por la interoperabilidad. Si bien esta rama particular de la interfaz de usuario no requerirá mucha interoperabilidad con la base de código de C ++ heredada, puedo evitar que esto se convierta en un problema en el futuro.
La alternativa es simplemente continuar con MFC, pero intente aprovechar el nuevo paquete de características que se envió con VS2008. Creo que esta es la opción más fácil, pero me preocupa la longevidad y no aprovechar la bondad que es .net ...
Entonces, ¿cuál escojo? Somos un equipo pequeño, por lo que es muy probable que mi recomendación sea aceptada como una dirección futura para nuestro desarrollo: quiero hacerlo bien.
¿MFC está muerto? ¿Es C # / Winforms el camino a seguir? ¿Hay algo más que me estoy perdiendo por completo? Ayuda muy apreciada!
Dependiendo de la aplicación y la disposición de sus clientes para instalar .NET (no todos son), definitivamente cambiaría a WinForms o WPF. La interoperabilidad con el código C ++ se simplifica enormemente refactorizando el código que no es UI en las bibliotecas de clase utilizando C ++ / CLI (como lo ha notado en su selección de etiquetas).
El único problema con WPF es que puede ser difícil mantener la apariencia actual. Pasar a WinForms se puede hacer manteniendo el aspecto actual de su GUI. WPF usa un modelo tan diferente que intentar mantener el diseño actual probablemente sería inútil y definitivamente no estaría en el espíritu de WPF. WPF también parece tener un bajo rendimiento en las máquinas anteriores a la Vista cuando se está ejecutando más de un proceso WPF.
Mi sugerencia es averiguar qué están usando sus clientes. Si la mayoría se ha mudado a Vista y su equipo está preparado para realizar una gran cantidad de trabajo en la GUI, yo diría omitir WinForms y pasar a WPF. De lo contrario, definitivamente mira seriamente WinForms. En cualquier caso, una biblioteca de clases en C ++ / CLI es la respuesta a sus inquietudes interoperativas.
Estoy de acuerdo con el sentimiento de WPF. La interfaz de usuario basada en etiquetas / XML parecería ser un poco más portátil que WinForms.
Supongo que también debes considerar a tu equipo, si no hay muchas habilidades actuales de C #, entonces ese es un factor, pero en el futuro, el mercado para los desarrolladores de MFC está disminuyendo y C # está creciendo.
Tal vez algún tipo de enfoque poco sistemático sería posible? Me he involucrado bastante en la recodificación de aplicaciones heredadas a C #, y siempre lleva mucho más tiempo de lo que usted estima, especialmente si mantiene algún código heredado o si su equipo no está familiarizado con C #.
Gracias a todos por sus respuestas, es tranquilizador ver que, en general, el consenso sigue mi línea de pensamiento. Estoy en la afortunada situación de que nuestro software también se ejecute en nuestro propio hardware personalizado (para la industria de transmisión), por lo que la elección del sistema operativo es realmente nuestra y recae sobre nuestros clientes. Actualmente estamos ejecutando XP / 2000, pero puedo ver un deseo de pasar a Vista pronto.
Sin embargo, también tenemos que mantener un control muy preciso sobre el rendimiento de la GPU, lo que supongo automáticamente descarta la aceleración de hardware y WPF. Debería haber hecho ese punto en mi publicación original, lo siento. Quizás es posible usar dos GPU ... pero esa es otra pregunta en total ...
El equipo no tiene experiencia significativa en C # y yo no soy un experto, pero creo que los beneficios generales a largo plazo de un entorno administrado probablemente superan el tiempo que tomará para ponerse al día.
Parece que Winforms y C # lo tienen por ahora.
No le da muchos detalles sobre lo que hace su código heredado o cómo está estructurado. Si tiene ciertos criterios de rendimiento, es posible que desee mantener parte de su base de código en C ++. Te resultará más fácil hacer interoperabilidad con tu código anterior si está expuesto de la manera correcta. ¿Puedes llamar al código actual de C # hoy? Puede valer la pena pensar en un proyecto para obtener esta estructura correcta.
Sobre el punto de WPF, podría argumentar que WinForms puede ser más apropiado. Mudarse a WinForms es un gran paso para usted y su equipo. ¿Quizás estén más cómodos con el cambio a WinForms? Está mejor documentado, tiene más experiencia en el mercado y es útil si aún necesita admitir clientes de Windows 2000.
Puede interesarle extender aplicaciones MFC con .NET Framework
Otra cosa a considerar es C ++ / CLI , pero no tengo experiencia con eso.
Si observara el cambio a C # y, por lo tanto, a .NET, consideraría Windows Presentation Foundation en lugar de WinForms. WPF es el futuro de los clientes inteligentes en .NET, y las habilidades que recoja podrán reutilizar si desea crear aplicaciones Silverlight alojadas en el navegador.
Soy un desarrollador en una aplicación que tiene un montón de código MFC heredado, y tenemos todas sus mismas preocupaciones. Un gran impulsor de nuestra estrategia fue eliminar tanto riesgo e incertidumbre como pudimos, lo que impidió evitar The Big Rewrite. Como todos sabemos, TBR falla la mayor parte del tiempo. Así que elegimos un enfoque incremental que nos permite preservar los módulos que no cambiarán en la versión actual, escribir nuevas características administradas, y funciones de transporte que están obteniendo mejoras en la administración.
Puedes hacer esto de varias maneras:
Aloje contenido de WPF en sus vistas de MFC (consulte aquí )
Para aplicaciones MFC MDI, cree un nuevo marco WinForms y aloje sus vistas MDI MFC (consulte aquí )
Alojar controles de usuario de WinForms en cuadros de diálogo y vistas de MFC (ver aquí )
El problema con la adopción de WPF (opción 1) es que requerirá volver a escribir toda su interfaz de usuario de una vez, de lo contrario, se verá bastante esquizofrénico.
El segundo enfoque parece viable pero muy complicado.
El tercer enfoque es el que seleccionamos y ha estado funcionando muy bien. Le permite refrescar selectivamente áreas de su aplicación, manteniendo la coherencia general y sin tocar cosas que no están rotas.
El paquete de características de Visual C ++ 2008 parece interesante, aunque no he jugado con él. Parece que podría ayudar con su problema de apariencia obsoleta. Si la "cinta" sería demasiado discordante para sus usuarios, podría consultar proveedores de control de MFC y / o WinForms de terceros.
Mi recomendación general es que el cambio incremental interoperativo + es definitivamente preferible a los cambios radicales.
Después de leer su seguimiento, definitivamente puedo confirmar que las ganancias de productividad del marco superan ampliamente la inversión en aprenderlo. Nadie en nuestro equipo había usado C # al comienzo de este esfuerzo y ahora todos lo preferimos.