c# - tutorial - ¿Cuáles son algunas técnicas para migrar una aplicación MFC grande a WPF/.NET?

xaml c# tutorial español (5)

Creo que tienes un buen manejo de las estrategias. Tenga en cuenta que un punto potencial de dolor al migrar a WPF es que no todos los controles tienen un controlador. Este es, desafortunadamente, el escenario de interoperabilidad más torpe. AFAIK, la única forma de interoperar con MFC y WPF es pasar por WindowsFormsHost . El paradigma de WPF también es radicalmente diferente de MFC / WinForms, por lo que puede haber algunos problemas de traducción allí.

Dado su gran base de códigos, pero funcional, legado, probablemente argumentaría a favor de su segundo enfoque. Comience con un control a la vez y conviértalo en WPF-y. Cree una interfaz bien definida entre su nuevo control administrado y el código base subyacente, luego trabaje contra esa interfaz. Si lo hace uno por uno, estará trabajando con un perfil de riesgo más bajo en la curva de aprendizaje de WPF (que es bastante pronunciada, imho).

Siento que es importante tener en cuenta que probablemente sugeriría el enfoque anterior si fuera a WinForms. El paradigma más cercano y la curva de aprendizaje relativamente suave serían mucho más fáciles de trabajar de una vez.

Actualmente estoy trabajando en una gran aplicación heredada de MFC MDI. Tiene una gran cantidad de elementos de la interfaz de usuario (barras de herramientas acoplables, controles de árbol personalizados, menús contextuales, etc.) Es una aplicación de procesamiento de imágenes, por lo que las vistas principales se representan mediante DirectX y OpenGL. El producto tiene aproximadamente 10 años y una de las prioridades aquí es actualizar el aspecto del mismo.

Sabiendo que Microsoft ha hecho un buen trabajo al proporcionar interoperabilidad entre C ++ / MFC y .NET, pensé que tendría sentido migrar la base de código de manera incremental. Con lo que estoy luchando ahora es por dónde empezar.

Un enfoque es extraer el marco MFC con WPF y reutilizar todo el código C ++ que podamos. Esto nos permitirá maximizar los beneficios de la arquitectura WPF, pero significará un largo período de desarrollo hasta que volvamos a ser completamente funcionales.

Otro enfoque es reemplazar los controles de MFC uno a la vez por sus homólogos de WPF. Esto nos permitirá trabajar incrementalmente. Mi preocupación con este enfoque es que significa que habrá una gran cantidad de puntos de conexión entre el código administrado y el no administrado y no estoy seguro de por dónde empezar a reemplazar cosas como el menú principal y las barras de herramientas.

¿O hay otra opción aquí que no estoy viendo?

Cualquier sugerencia o enlaces a información sobre este tema serán apreciados.

Actualización: DavidK planteó algunas preguntas excelentes, así que estoy agregando las motivaciones detrás de esto.

1) Desarrollo futuro del producto.

Este producto todavía se está desarrollando activamente con nuevas funciones que se agregan de forma regular. Pensé que tendría mucho sentido intentar y migrar lentamente hacia C # / WPF. En mi experiencia limitada con C # / WPF, encontré que los aumentos de productividad son increíbles en comparación con el trabajo en C ++ / MFC.

La otra gran cosa que estamos obteniendo con WPF es la capacidad de aprovechar los sistemas de múltiples cabezales. Las aplicaciones MFC están limitadas a un solo marco de nivel superior, lo que hace que sea muy difícil aprovechar múltiples monitores.

2) Retención y contratación de empleados.

Cada vez es más difícil encontrar desarrolladores que estén dispuestos a trabajar en MFC. También es importante para el desarrollo de la carrera de los desarrolladores actuales obtener exposición a las nuevas tecnologías.

FWIW, mientras tanto, puede usar el paquete de características de MFC (disponible con VS2008 SP1) para darle a su aplicación un aspecto de Office 2007 bastante rápido (incluso puede agregar una cinta si es algo que les gustaría a sus usuarios, aunque esto sería más involucrado.) Renové la interfaz de usuario de una antigua aplicación MFC usando estas nuevas clases en un solo día y ahora, para ser justos, se ve fantástico, y mis usuarios están muy satisfechos (puede admitir toda una serie de apariencias y combinaciones de colores .) MS optó por el kit de herramientas BCG, pero hay otros disponibles si desea pagar una pequeña cantidad de dinero (por ejemplo, CodeJock).

Sé que esto no responde a tu pregunta, pero si lo que buscas son cambios en la interfaz de usuario, entonces vale la pena echarle un vistazo.

No creo que haya una forma más fácil de no haberlo cubierto, aunque probablemente dependerá en gran medida de qué tan separada esté la lógica subyacente de la capa UI.

Sin querer parecer negativo: ¿estás seguro de que valdrá la pena? Si escribiera una aplicación grande desde cero, no empezaría con C ++ y MFC ahora, pero viendo dónde se encuentra, ¿qué ganará realmente al reescribirla? ¿Eso agregará una nueva característica que los usuarios pagarán? ¿Hay algún usuario al que cortarías que no podrá ejecutar la nueva versión? No puedo evitar sospechar que obtendrá un retorno de la inversión mucho mayor al observar algunas cosas relativamente simples que podría hacer para mejorar el aspecto de la aplicación tal como está. Por ejemplo, ¿tiene un manifiesto estilo XP para que los controles comunes tengan el aspecto de XP? ¿Unos pocos días dedicados a actualizar bits (p. Ej., Utilizando los nuevos cuadros de diálogo de archivos de estilo) le brindarán la mayor parte del camino a un nuevo aspecto brillante? Tenga en cuenta que incluso el Office 2007 más nuevo y brillante fue implementado por Microsoft con controles Win32 normales.

Revisando esto porque he reemplazado con éxito nuestra interfaz de usuario de MFC de nivel superior (el marco principal, las ventanas y las barras de herramientas) con WPF.

Como resultado, nuestro código de dibujo principal simplemente necesita que se le entregue un HWND para representarlo. Esto hizo que sea realmente fácil reutilizar la mayor parte de nuestro código base de C ++ existente.

Aquí hay un resumen rápido de las piezas clave del enfoque que tomé:

Usó la clase .NET HwndHost para alojar un HWND para que el código de dibujo de C ++ se renderice en
Se crearon envoltorios de C ++ / CLI para cualquier código C ++ nativo que debiera estar expuesto al código de UI de WPF / C #
Dejó la mayoría de los diálogos de MFC tal como están en el código nativo de C ++. Esto minimiza la cantidad de trabajo necesario para finalizar la interfaz de usuario. Los cuadros de diálogo de MFC se pueden migrar a WPF a lo largo del tiempo.

Como nota al margen, estamos usando SandDock y SandRibbon de Divelements y hemos estado muy contentos con ellos hasta ahora.

Tuve que hacer lo mismo en un proyecto usando WinForms antes. Necesitábamos migrar nuestro proyecto MFC a .NET 1.1 y decidimos tomar toda la funcionalidad central de la aplicación MFC y escribir envoltorios administrados alrededor de todos ellos. Luego escribimos un extremo frontal de WinForms y conectamos el código de C ++ heredado poco a poco. Creo que hicimos la elección correcta a largo plazo. No puedo imaginar cómo lo habríamos hecho si hubiéramos intentado preservar el extremo delantero de MFC al mismo tiempo.