que - "Nadie debería usar MFC nunca más" ¿Por qué?
mfc windows 10 (6)
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 corté más árboles.
No digo que el AX sea 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 un á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.
¿Es cierto que "nadie debería usar MFC nunca más"?
¿Y por qué es eso?
Es simplemente una tecnología más antigua: hay tecnologías más nuevas y brillantes que son mucho más fáciles de usar ...
Es un poco difícil ver una buena razón por la cual un nuevo proyecto usaría MFC / C ++ ... a menos que sea la tecnología que un equipo de desarrollo conoce. Un equipo con experiencia en C ++ y 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.
Podría decirse que nadie debería haber usado MFC (hablando como alguien que ha estado expuesto 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 mal uso deliberado del lenguaje C ++. Por supuesto, si tienes un gran proyecto de MFC, probablemente estés atascado.
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.
A pesar de que 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 como quiera llamarlas) son populares, y no todas tienen instalado .NET Framework. 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 que no son .NET además de MFC que podrías usar. Pero MFC sigue siendo una buena opción.
Si ve la charla de Project Centennial desde 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 utilizan Ribbons / ToolBar / Menus / Dialog, etc., MFC podría seguir siendo popular incluso con todos sus bits estrafalarios.