¿Sigue habiendo un caso para MFC

Question

¿Cuáles son las características atractivas de MFC? ¿Por qué lo seleccionarías para un nuevo proyecto?

Answer 1

Quick Tour Of New MFC Functionality

he oído que tienen un nuevo control de la cinta. Si te gusta este tipo de complejidad. Aquí hay una captura de pantalla de una aplicación recién generado:

http://blogs.msdn.com/blogfiles/vcblog/WindowsLiveWriter/QuickTourOfNewMFCFunctionality_C777/Wizard%20Generated%20with%20accelerator%20tips_2.jpg

En realidad, es sólo una actualización del widget. Entonces, ¿necesitamos más widgets?

Answer 2

La ventaja de MFC es que es aún mejor que la codificación de desnudar Win32 y se puede distribuir un .exe nativa que no requiere un tiempo de ejecución 23-50Mb como .Net.

Ahora, si le preocupan esas cosas, existen alternativas mejores: C++ Builder, WxWidgets, etc. Pero algunos lugares no considerarán herramientas que no sean de Microsoft.

Answer 3

Al parecer, sigue siendo una buena opción para las aplicaciones para dispositivos de mano basados ​​en Windows, como dispositivos de punto de venta. En estos, los recursos son limitados, por lo que cosas como el manejo de la memoria se vuelven más importantes.

Answer 4

Podría ordenar de alguna manera la pregunta, ¿por qué seleccionaría C++ sobre C# para una aplicación de escritorio? C++ todavía ofrece ventajas de velocidad que son importantes para algunas aplicaciones (trabajo para una empresa que crea software para comercio electrónico. La velocidad importa mucho).

Si se va a desarrollar una aplicación de escritorio para Windows destinada sólo en C++, a continuación, MFC es la opción más madura, con una gran cantidad de código libre basado en MFC en el Internet, una gran cantidad de conocimientos.

Answer 5

La API de Windows existente está completamente basada en C. Si desea usar C++ (y probablemente debería), MFC es la opción lógica si desea seguir siendo nativo (es decir, no usar .NET).

MFC es simplemente un conjunto de clases orientadas a objetos en la parte superior de la API de C. Además de algunas clases adicionales de "ayuda" que facilitan las tareas cotidianas.

Answer 6

En el diseño & ¿méritos técnicos? Lamento ser categórico, pero ninguno. Es un diseño pobre, una abstracción enormemente permeable donde tienes que recurrir a la programación API de Win32, usa mal C++ atrozmente, y está firmemente enfocado en la tecnología de ayer: no obtendrás una experiencia de usuario moderna (¡o incluso atractiva!) una aplicación MFC. Si puede obtener desarrolladores de C# y no tiene limitaciones graves de hardware, vaya con WinForms.

Factores externos como la disponibilidad de competencias para contratar, programas de formación y componentes de terceros, por otro lado, todavía pueden extender su vida útil, al menos para algunos tipos de aplicaciones: pequeña & simple, dirigida a aplicaciones especiales con razonablemente pocos usuarios, preferiblemente internos.

Answer 7

Aquí hay una posibilidad: imagine una aplicación que requeriría una gran cantidad de memoria, por ejemplo, un programa de gráficos, un juego o tal vez alguna aplicación empresarial de alto rendimiento. No es ningún secreto que las aplicaciones .NET acaparan la memoria, en tal caso, es posible que desee una aplicación MFC sin problemas para el núcleo de su aplicación. Siempre puede cargar y usar componentes .NET, controles, etc. a través de contenedores COM llamables o directamente a través de C++/CLI.

Dicho todo esto: MFC es un dolor. Considere WTL en su lugar: aún puede llamar a .NET si lo necesita, de la misma manera que mencioné anteriormente para MFC.WTL es mucho más agradable que MFC :-)

Answer 8

MFC era una buena opción hace 10 años. Todavía es un buen contenedor sobre la API de Win32, pero desafortunadamente obsoleto.

El QT de Trolltech es la mejor opción con una gran ventaja: es independiente de la plataforma. Con MFC estás condenado a Windows.

Answer 9

He escrito código multiplataforma durante años, así que cuando tengo que escribir algo, siempre tengo una capa de abstracción muy delgada entre él y el sistema requiere casi todo, excepto llamadas posix. De esta forma, puede codificar para que sea compatible con MFC, pero con bastante facilidad convierta una API diferente más adelante si es necesario. Mi conjunto básico de bibliotecas de C++ que utilizo para todo lo hace con una pequeña clase de sistema. Actualmente lo tengo usando MFC para Windows y también lo tengo usando XWindows para Linux y una versión nativa de Mac también. Y más tarde cuando lo porte para una computadora de mano, debería ser bastante sencillo.

Si quieres echar un vistazo, es LGPL'ed y se encuentra en:

http://code.google.com/p/kgui/

Answer 10

creo que no .. MFC perdería en

• nivel de abstracción
• Tiempo de desarrollo
• Tiempo de resolución de problemas
• Curva de aprendizaje para nuevo d evelopers
• prueba de futuro (aunque ahora que es cuestionable .. con algo nuevo que viene cada 3-4 años)
• Encontrar buenas personas que conocen su MFC
• Fácil de usar los controles

El único lugar donde MFC probablemente pasaría furtivamente es si tienes algunas aplicaciones que requieren mucho rendimiento, como que tienes cosas en la pantalla que deben volver a dibujarse cada 10 mseg o 1 segundo. Las aplicaciones "administradas" todavía no han logrado superar ese obstáculo.

MFC fue un paso importante en la evolución, pero ahora hay mejores opciones disponibles.

Answer 11

Si está desarrollando Windows CE y aplicaciones móviles en C++, como ya lo mencionó Einar, MFC es una buena opción. Si elige esta opción, MFC también se convierte en una opción razonable para el escritorio, ya que puede usar el mismo código en computadoras de escritorio y dispositivos de mano. MFC sigue siendo una buena combinación de rendimiento/fácil de implementar en este escenario. Personalmente, uso MFC junto con las bibliotecas de Stingray en estos entornos, lo que ofrece una interfaz muy buena, un buen rendimiento y es rápida y fácil de implementar.

Answer 12

Todavía uso MFC para todo tipo de aplicaciones. MFC obtuvo una mala reputación de sus primeras implementaciones, pero ahora es excelente. Me resulta bastante más conveniente que WTL también. Además, las herramientas de GUI en Visual Studio ya están configuradas para facilitar el desarrollo rápido de GUI con MFC, asignación de controles a variables, DDX, etc.

Para aplicaciones de escritorio que pretendo una amplia distribución, sigo usando las aplicaciones nativas de Windows , generalmente en MFC, porque todavía no estamos en un punto en el que pueda depender de sus clientes para que la versión de .NET que usará esté instalada y pedirles que la instalen hará que pierda ventas, no para Mencione el dolor de cabeza del servicio al cliente cuando tenga problemas para instalar .NET como resultado de tratar de hacer que su aplicación se ejecute.

Answer 13

Yo diría que la velocidad y la huella son buenas razones sobre .NET.

Probablemente sea cierto que le resultará difícil encontrar buenos programadores de MFC, pero eso es tanto porque los lenguajes modernos promueven técnicas de programación perezosa y la mayoría de los cursos de programación gravitan hacia ellos ya que son más fáciles de enseñar.

Answer 14

Además de win32 api en sí, MFC es la única tecnología de programación dominante de Windows que todavía está viva y bien en 2011 después de más de 15 años. Allá por 2001 todos decían 'MFC está muerto, ahora todo es Winforms'; en 2005 todo el mundo dijo "MFC está muerto, ahora todo es XAML"; ahora es 2011 y Winforms y XAML están muertos (OK XAML quizás no esté realmente muerto, pero mucho más allá de su mejor momento) y MFC aún se está actualizando con los últimos desarrollos (ribbon, extensiones Aero, Win7 API, etc.).

Por supuesto, eso no garantiza nada para el futuro, pero en esos 15+ años, un lote de código MFC escrito, y seguirá en uso durante la próxima década o décadas. Puede que no sea la tecnología más bonita, pero está bien entendida (son puntos buenos y malos) y no es un objetivo móvil como otras tecnologías exageradas, lo que significa que las personas que realmente quieren hacer cosas pueden confiar en ello (bueno, más que en las alternativas, de todos modos).

(mismo ocurre con C++, por cierto)