Prueba futura de una aplicación de interfaz de usuario grande: MFC con paquete de características 2008, o C# y formas de pago?

Question

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 una conclusión interna de que nuestro producto parece anticuado en comparación a 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. Supongo que 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!

Answer 1

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.

Puede hacerlo de varias maneras:

1. alojar contenido de WPF en sus puntos de vista MFC (véase here)

2. Para aplicaciones MDI de MFC, crear un nuevo marco WinForms y alojar sus puntos de vista MFC MDI (ver here)

3. controles WinForms usuario de acogida en MFC Diálogos y Vistas (ver here)

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 hemos seleccionado y ha funcionado 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 la interoperabilidad + cambio incremental es definitivamente preferible a los cambios radicales.

---

Después de leer su seguimiento, lo puedo confirmar que las ganancias de productividad del marco superan con creces la inversión en aprenderlo. Nadie en nuestro equipo había usado C# al comienzo de este esfuerzo y ahora todos lo preferimos.

Answer 2

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.

Answer 3

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 debe considerar a su equipo, si no hay muchas habilidades actuales de C#, entonces ese es un factor, pero en el futuro el mercado de desarrolladores de MFC está disminuyendo y C# está creciendo.

¿Tal vez sería posible algún tipo de enfoque por partes? 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#.

Answer 4

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.

Answer 5

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

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

Usted puede estar interesado en Extending MFC Applications with the .NET Framework

Otra cosa a considerar es C++/CLI, pero no tengo experiencia con ella.

Answer 6

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. Tal vez es posible usar dos GPU ... pero esa es otra pregunta en total ...

El equipo no tiene ninguna experiencia significativa en C# y yo no soy un experto, pero creo que los beneficios generales a largo plazo de una el entorno administrado probablemente supere el tiempo que tomará para ponerse al día.

Parece que Winforms y C# lo tienen por ahora.