2010-01-22 12 views

Respuesta

13

Podría decirse que nadie debe jamás han utilizado MFC (hablando como alguien que tiene estado expuesto a ella desde MFC 1.0). Siempre hubo mejores tecnologías para el desarrollo de GUI, desde SQLWindows de Gupta y Borland's Delphi hasta el propio Visual Basic de Microsoft. Y hoy en día tenemos .NET o, quizás más parecido a MFC, Qt.

MFC en sí era una serie de hacks, y a menudo abusos deliberados del lenguaje C++. Por supuesto, si tienes un gran proyecto de MFC, probablemente estés atascado.

+5

MFC es el trabajo de los demonios. – jkp

+5

No es tan malo. Funciona de una manera bastante sólida. Claro que es peculiar, pero la mayoría de la gente parece odiarlo porque "usa macros", que es un argumento pobre. –

+0

@John: Suena como C++ en general para mí ;-) – Joey

4

Es simplemente una tecnología más antigua: no son más recientes, las tecnologías más brillantes por ahí que son mucho más fáciles de usar ...

+2

Ojalá pudieras usar esas tecnologías "más brillantes" con código nativo ... Las tomaría como una toma ... * suspiro * – Goz

+1

+1 por mucho más fácil de usar (y mantener). Prefiero ver el código C# que el código MFC. –

3

Es un poco difícil de ver una buena razón por la cual un nuevo proyecto usaría MFC/C++ ... a menos que sea la tecnología que sabe un equipo de desarrollo. Un equipo con experiencia en C++ & MFC que salta al por mayor en .NET/WPF en un nuevo proyecto va a perder mucho tiempo.

Joel escribió un buen artículo sobre este camino de regreso (creo), pero no puedo encontrarlo. Básicamente, necesitas una razón comercial para cambiar la tecnología. "Es viejo y feo y queremos ser geniales con WPF" no es un motivo comercial.

+0

El mejor interés de los desarrolladores es mantenerse al día con las tecnologías/marcos actuales. Especialmente aquellos que son aceptados por la industria. – danjarvis

+0

En muchas industrias, quieren software que use tecnologías probadas y comprobadas. En tales áreas, incluso .NET se considera demasiado inmaduro como para ser confiable. –

+0

Está en el _a_ interés del desarrollador. Pero eso no es lo mismo que una compañía que tiene un equipo de experimentados desarrolladores de C++/MFC. Tiene sentido que sigan con lo que saben hasta que puedan capacitar a su gente con algo más nuevo. –

2

Algunos días me siento un poco como Paul Bunyan en el sentido de que estoy balanceando mi MFC Axe y derribando muchos árboles solo para ver aparecer las nuevas motosierras. Todos dicen cuánto mejor es la motosierra, así que aprendo a usar la motosierra y empiezo a cortar esos árboles, y luego aparece el feller-buncher, y todos dicen cuánto mejor es el feller-buncher, así que aprendo a usar el feller -Buncher y yo cortamos más árboles.

No estoy diciendo que el AX es mejor que el feller-buncher, no lo es, pero si ya tienes el hacha, y ya sabes cómo usar el hacha, y todo lo que tienes que hacer es cortar una árbol ...

A veces el demonio que conoces es mejor que el que no conoces.

FWIW: casi todo el SDK de Windows se basa en una macro; es casi como #ifdef y #define, es un lenguaje de desarrollo completo en sí mismo.

7

No, no es verdad. Las afirmaciones de ese tipo siempre son incorrectas, porque para cada proyecto y cada situación debe evaluar nuevamente las bibliotecas y los idiomas. Y simplemente descartar MFC sin una buena razón es incorrecto.

Aunque MFC ha existido durante años y mucha gente ya no quiere usarlo para nuevos proyectos, todavía puede ser la mejor opción dependiendo del proyecto. Sí, .NET y sus libs de interfaz de usuario son en la mayoría de las situaciones la mejor opción para los nuevos proyectos de hoy. Pero si quiere un espacio de memoria pequeño, un tiempo de arranque muy rápido o su aplicación tiene que ejecutarse en computadoras muy limitadas, MFC aún puede ser una buena opción.

Por ejemplo, las netbooks (o lo que sea que quiera llamarlas) son populares, y no todas tienen el .NET Framework instalado. Y aquellos que solo tienen 512 MB-1 GB de RAM, es posible que no desee que su aplicación use ese marco.

Y, por supuesto, hay otras bibliotecas no .NET además de MFC que podría usar. Pero MFC sigue siendo una buena opción.

0

Si ve la conversación Project Centennial de Build 2015, muestra que Adobe sigue usando MFC en sus productos de Adobe. Están utilizando mfc100 de VS2010 para hacer una aplicación UWP desde los componentes Win32/COM/MFC, por lo que MFC aún se está utilizando.

Hasta que Microsoft proporcione un Marco de interfaz de usuario de C++ con los elementos de la interfaz de usuario que las aplicaciones de escritorio utilicen Ribbons/ToolBar/Menus/Dialog, etc., MFC podría seguir siendo popular incluso con todos sus peculiares bits.

Cuestiones relacionadas