Es factible convertir una aplicación MFC C++ basada en escritorio a una aplicación web

Question

Tengo una aplicación muy grande, 1,5 millones de líneas de C++, que actualmente se basa en MFC utilizando la arquitectura Document/View. La aplicación incluye muchos gráficos vectoriales en 3D, hojas de cálculo y muchos diálogos y Windows. Dentro de las limitaciones del DVA está bastante bien escrito, ya que no hay una lógica de programa significativa en la interfaz de usuario, y cualquier cosa que se pueda hacer usando la interfaz de usuario también se puede llevar a cabo programáticamente usando una interfaz de Automatización COM/OLE.

A petición de un número de usuarios, he estado jugando con la idea de crear una interfaz de navegador para el programa, donde el programa se ejecuta en un servidor. Los pensamientos hasta el momento son convertir todas las interfaces COM a DCOM y reescribir/portar la interfaz de usuario a Java. La experimentación inicial muestra que esto será una gran cantidad de trabajo.

¿Alguien más tiene alguna idea para una implementación más fácil? ¿Alguien se encuentra con herramientas de refactorización o similares específicamente para ayudar a este tipo de puerto?

Answer 1

La respuesta corta es que es factible, no use java, y que será una cantidad considerable de trabajo.

Hace unos años (alrededor del tiempo de IE5) un cliente me pidió que respondiera una pregunta similar a esta. La aplicación en cuestión era una aplicación de escritorio de tres niveles bien estructurada.

El resultado del estudio fue que es posible. Las opciones consideradas fueron Java y CGI, usando CORBA o COM/DCOM. Se consideró la creación de un applet de Java, pero se descartó porque no habría sido muy diferente a la versión de escritorio de C++.

El enfoque adoptado consistía en tomar el nivel de backend y convertirlo en una aplicación de servidor situada detrás de una capa cgi. La interfaz de usuario se reescribió en gran medida utilizando lo que ahora conocemos como Ajax, es decir, Javascript y HTML. La interfaz de usuario se dividió entre los elementos del navegador y los elementos del servidor.

Consideré escribir una herramienta para convertir documentos, vistas y diálogos y envolverlos en un formato compatible, sin embargo después de mucho análisis se hizo obvio que no era realmente factible hacer esto porque el MFC está bastante acoplado a la API Win32, y a sí mismo. Dependiendo de la cantidad de diálogos, puede valer la pena escribir algo para convertirlos.

Encontré, incluso en un sistema bien estructurado, que un poco de código que debería haber estado en el backend se había filtrado en la parte delantera.

Si tuviera que hacer lo mismo ahora, hay algunas excelentes bibliotecas de JavaScript que ayudarían, pero igual seguiría haciendo lo mismo en el navegador usando Ajax, posiblemente con algo como qooxdoo o YUI. Probablemente también me gustaría ver el uso de XUL y mover al menos la mayoría de los cuadros de diálogo al back-end.

Lo único que me preocupa de su lista de requisitos son los gráficos vectoriales en 3D, aunque puede haber algunos millajes en this JS toy o .

Este es solo un breve resumen, ya que estoy tratando de evitar escribir una disertación.

Answer 2

Sería una gran cantidad de trabajo, pero ya has hecho el buen diseño, ¡ya estás a la mitad!

Comenzaría moviendo su interfaz de usuario de MFC en un archivo ejecutable independiente, y utilizándolo para controlar el código de fondo. Una vez que hayas hecho eso (lo que debería ser relativamente fácil ya que solo estás reempacando el código existente), entonces tendrás una mejor idea de si será capaz de manejar a varios usuarios que se conectan a un solo servidor de fondo.

Una vez que haya reparado, puede ver todas las áreas donde necesita implementar la conectividad con el back-end, y puede comenzar a volver a escribir la interfaz de usuario en cualquier idioma o plataforma que desee.

Para una interfaz web, escribiría el código del servidor web que interactuó con su servidor de fondo. De esta forma obtendrá un acoplamiento mucho más fácil y tendrá menos problemas de seguridad y conectividad de los que preocuparse. Siempre pienso que el navegador webserver + es la capa de presentación en una aplicación n-tier.

En cuanto a las tecnologías web, puede usar flex, activex, silverlight o posible jquery/jsext para obtener el contenido enriquecido en el navegador.

Answer 3

Antes de considerar convertir la aplicación MFC a una aplicación web, le sugiero que lea "Avoiding The Uncanny Valley of User Interface" de Jeff Atwood.

Si está considerando o creando activamente aplicaciones Ajax/RIA, debe considerar el diseño de la interfaz de usuario de Uncanny Valley. Cuando crea una aplicación de estilo "escritorio en el navegador web", está violando las expectativas no escritas de los usuarios sobre cómo debería verse y comportarse una aplicación web. Esta elección puede tener un impacto negativo significativo en la capacidad de aprendizaje, la facilidad de uso y la adopción.

No sé cómo se ve tu aplicación y qué tan "web portable" es, pero quizás hacer una copia exacta de la aplicación para la web no es la mejor opción.

Answer 4

Hace unos años jugué con esto, pero una vez intenté tomar una pequeña aplicación y compilarla como un componente X activo que luego podría usarse fácilmente en una página web. (Esta aplicación se basó en un formulario creado con Borland C++ Builder por lo que era bastante trivial convertirlo en un componente activo de X. No podía juzgar cuán difícil sería envolver su aplicación MFC D/V como un activo Componente X).

Era necesario registrar el componente X activo en la máquina del usuario (también bastante trivial, pero tenía que volver a registrar cada nueva versión del componente - sentí que estaba llenando el registro) y ahora Internet Explorer lanza advertencias con páginas web usando activeX por lo que requeriría que el usuario bajara el nivel de seguridad en IE para evitar que se queje

Answer 5

Sí, hemos hecho esto con una gran aplicación de C++ (Borland) que podría describirse mejor como una arquitectura de "gran bola de barro".

Tienes algunos problemas interesantes por delante, pero hicimos un front-end muy atractivo y 'webby' (el prototipo está en ASP.NET pero podría ser cualquier cosa incluyendo Java) que en gran medida dispara eventos en la aplicación de escritorio que se ejecuta el servidor, luego muestra los gráficos, tablas y texto resultantes. Somos flexibles en la forma en que se muestran gráficos como, por ejemplo, .PNG, objetos flash o .SVG según el navegador

Funciona sorprendentemente bien y solo tuvimos que implementar algunos meses de programador una vez que tuvimos un modelo resuelto (el diseño era un problema).

Por el momento, solo hemos implementado un subconjunto útil de toda la aplicación de escritorio, pero a medida que continuamos, el back-end se separará más limpiamente de la interfaz (y reducirá su tamaño).Si ya tiene una buena separación entre GUI y back-end, entonces esa es una gran ventaja.

También nos fijamos en una producción en gran medida automática de la interfaz web de la aplicación, pero decidimos en la etapa de diseño se va a parecer demasiado parecido a una aplicación que se ejecuta en Windows32 una ventana del navegador ....

Answer 6

Vea si Wt podría satisfacer sus necesidades. Es un kit de herramientas de aplicaciones web C++.