El futuro de corrección de una gran interfaz de usuario de la Aplicación de MFC con 2008 Feature pack, o C# y Winforms?

Question

Mi empresa ha desarrollado una larga duración del producto mediante MFC de Visual C++ como el estándar de facto para el desarrollo de la IU.Nuestra base de código contiene un MONTÓN de legacy/arcaico código que debe mantenerse en funcionamiento.Algunos de este código es mayor que yo (escrito originalmente en los finales de los 70) y algunos miembros de nuestro equipo están todavía en Visual Studio 6.

Sin embargo, una conclusión que afortunadamente ha sido alcanzado internamente que nuestro producto es de aspecto algo anticuado en comparación con nuestros competidores, y que algo debe hacerse.

Actualmente estoy trabajando en una nueva área de la interfaz de usuario que es bastante diferente al del resto del producto.Por lo tanto, he tenido la oportunidad de probar la 'nueva' tecnología de pilas como una especie de campo de pruebas antes de que el largo proceso de mover más el resto de la interfaz de usuario comienza.

He estado usando C# con Windows Forms y el .net framework por un tiempo en mi tiempo libre y disfrutar de ella, pero estoy un poco preocupado acerca de los dolores de cabeza causados por la interoperabilidad.Mientras que esta rama de la interfaz de usuario no requiere de mucho interoperabilidad con el legado de C++ codebase, puedo prever que esto se convierta en un problema en el futuro.

La alternativa es sólo para continuar con MFC, pero trate de tomar ventaja de la nueva feature pack que se entregan con VS2008.Esto supongo que es la opción más fácil, pero me preocupa la longevidad y no aprovecharse de la bondad que es .net...

Así que, ¿cuál elijo?Somos un equipo pequeño, así que mi recomendación muy probable, que de ser aceptado como una dirección de futuro para nuestro desarrollo - quiero hacerlo bien.

MFC es muerto?Es C#/Winforms el camino hacia adelante?¿Hay algo que estoy totalmente ausente?Ayuda muy apreciada!

Answer 1

Soy un desarrollador de una aplicación que tiene un montón de legado código de MFC, y tenemos todos tus mismas inquietudes.Un gran impulsor de nuestra estrategia fue la de eliminar el riesgo y la incertidumbre como pudimos, lo que significaba evitar La Gran Reescribir.Como todos sabemos, TBR falla la mayoría del tiempo.Así que elegimos un enfoque incremental que nos permite preservar los módulos que no cambian en la versión actual, la escritura de nuevas funciones administrado, andporting características que están consiguiendo mejoras para el administrado.

Usted puede hacer esto de varias maneras:

1. Host de contenido de WPF en el MFC vistas (ver aquí)

2. Para MFC MDI aplicaciones, crear un nuevo WinForms marco de host y el MFC MDI vistas (ver aquí)

3. Host WinForms controles de usuario en MFC Diálogos y puntos de vista (ver aquí)

El problema con la adopción de WPF (opción 1) es que será necesario volver a escribir todo de su interfaz de usuario a la vez, de lo contrario, se verá bastante esquizofrénico.

El segundo enfoque se ve viable, pero muy complicado.

El tercer enfoque es el que está seleccionado y ha estado trabajando muy bien.Permite selectivamente la actualización de las áreas de su aplicación, mientras que el mantenimiento de la coherencia global y de no tocar las cosas que no están rotas.

El Visual C++ 2008 Feature Pack se ve interesante, yo no he jugado con ella, aunque.Parece que podría ayudar con el problema de mirar anticuado.Si la "cinta de opciones" sería demasiado chocante para sus usuarios, usted podría mirar a terceros MFC y/o WinForms control de los vendedores.

Mi recomendación general es que la interoperabilidad + cambio incremental es definitivamente preferible a cambios radicales.

---

Después de la lectura de su seguimiento, definitivamente puedo confirmar que el aumento de la productividad del marco superan con creces la inversión en el aprendizaje de la misma.Nadie en nuestro equipo había utilizado el C# al inicio de este esfuerzo y ahora todos nos prefieren.

Answer 2

Dependiendo de la aplicación y la disposición de sus clientes a instalar .NET (no todos ellos), definitivamente, me gustaría pasar a WinForms y WPF.Interoperabilidad con código de C++ es muy simplificado mediante la refactorización no-código de interfaz de usuario en las bibliotecas de clase, el uso de C++/CLI (como usted señala en su selección de etiquetas).

El único problema con WPF es que puede ser difícil mantener el actual look-and-feel.Movimiento para WinForms se puede hacer mientras se mantiene la apariencia de su interfaz gráfica de usuario.WPF utiliza un modelo diferente que intentar mantener el diseño actual probablemente sería inútil y definitivamente no sería en el espíritu de WPF.WPF también, al parecer, tiene un rendimiento deficiente en pre-máquinas de la Vista cuando más de uno de WPF se ejecuta el proceso.

Mi sugerencia es averiguar lo que los clientes están utilizando.Si la mayoría se han trasladado a la Vista y su equipo está preparado para poner en un montón de GUI trabajo, yo diría que saltar WinForms y mover a WPF.De lo contrario, definitivamente se verá seriamente en WinForms.En cualquier caso, una biblioteca de clases en C++/CLI es la respuesta a su interoperabilidad preocupaciones.

Answer 3

No dar muchos detalles sobre lo que el código de la herencia hace o cómo se estructura.Si usted tiene ciertos criterios de rendimiento que usted podría querer mantener un poco de su código fuente en C++.Usted tendrá un tiempo más fácil de hacer de interoperabilidad con su viejo código si es expuesto en el camino correcto - ¿puede usted llamar a la existente base de código de C# hoy?Podría ser vale la pena pensar en un proyecto para conseguir esta estructura derecho.

En el punto de WPF, se podría argumentar que WinForms, puede ser más apropiado.Movimiento para WinForms es un gran paso para que usted y su equipo.Tal vez puede ser más cómodo con el movimiento para WinForms?Es mejor documentado, más experiencia en el mercado, y útil si usted todavía necesita para apoyar a los clientes de windows 2000.

Usted podría estar interesado en La ampliación de las Aplicaciones de MFC con el .NET Framework

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

Answer 4

Gracias a todos amablemente por sus respuestas, es reconfortante 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 ejecuta en nuestro propio hardware (para la industria de la televisión) - para la elección del sistema operativo es realmente nuestro y es de empuje a nuestros clientes.Actualmente estamos ejecutando XP/2000, pero puedo ver a un deseo de subir a la Vista pronto.

Sin embargo, también es necesario mantener un control muy preciso sobre el rendimiento de la GPU, que supongo que automáticamente descarta WPF y la aceleración de hardware?Yo debería haber hecho ese punto en mi post original - lo siento.Tal vez es posible utilizar dos tarjetas gráficas...pero esa es otra cuestión totalmente...

El equipo no tiene ningún significativa C# experiencia y yo no soy un experto mí mismo, pero creo que el total de los beneficios a largo plazo de un entorno administrado probablemente mayores que el tiempo va a tomar para llegar a la velocidad deseada.

Parece Winforms y C# tengo por ahora.

Answer 5

Fueron a buscar a mover a C# y por lo tanto .NETA, yo consideraría Windows Presentation Foundation en lugar de los formularios windows forms.WPF es el futuro de smart clientes .NET, y las habilidades de recoger usted será capaz de volver a utilizar si usted quiere hacer hospedada en el explorador de aplicaciones de Silverlight.

Answer 6

Estoy de acuerdo con el WPF sentimiento.Tag/XML de la interfaz de usuario basada parece ser un poco más portátil que WinForms.

Supongo que también tienes que considerar tu equipo, si no hay una gran cantidad de corriente C# habilidades, a continuación, que es un factor, pero de cara al futuro el mercado para MFC desarrolladores está disminuyendo y C# es creciente.

Tal vez algún tipo de enfoque poco sistemático sería posible?He estado involucrado con la recodificación de las aplicaciones heredadas a C# un poco, y siempre se tarda mucho más de lo que cabría estimar, especialmente si usted está manteniendo algunas código de la herencia, o de su equipo no es que estén familiarizados con C#.