C ++ MFC vs .NET?
Mes collègues utilisent Visual Studio 2002 et utilisent le C++ MFC. Je développe en C #.
Il n'y a eu aucun problème auparavant, mais nous nous demandons maintenant si nous devons vraiment nous développer dans des environnements différents. Mes collègues pensent (bien sûr) que je devrais passer au C++ MFC. Je pense qu'ils peuvent utiliser .NET au lieu de MFC.
Est-il utile d'apprendre le MFC? Cela semble un peu dépassé, ou je me trompe? Quels sont les arguments contre et pour .NET par rapport au MFC?
Modifier:
Nous développons des systèmes de processus et des applications d'assistance pour l'industrie nucléaire. L'application principale est un émulateur qui émule un ancien système informatique et utilise C++/MFC. Il est très critique en termes de temps, peut-être que le noyau devrait encore être en C++ natif. Mais l'interface graphique de l'émulateur et toutes les applications environnantes ne sont pas particulièrement critiques.
Et y a-t-il une vraie raison pour laquelle vous devriez remplacer l'application MFC existante?
J'ai utilisé à la fois MFC et Windows Forms depuis très longtemps. Je suis de l'industrie du jeu vidéo, j'ai donc dû écrire de nombreuses applications de bureau au fil des ans, et avant .net, MFC était extrêmement utile. Même avant cela, j'écrivais des outils en Win32 pur.
Le MFC avait certainement ses caprices, mais dans l'ensemble, cela a rendu la vie beaucoup plus facile. Il était très facile d'intégrer OpenGL et Direct3D dans des vues personnalisées, et une fois que vous avez pris le temps d'écrire des contrôles personnalisés était un jeu d'enfant. Mieux encore, je pouvais simplement coder en C++ pur, qui se trouvait juste être mon langage de choix. De plus, j'ai trouvé que le MFC était très efficace et accrocheur.
Peu à peu, MFC a commencé à obtenir un support de bibliothèque de contrôle externe, en particulier des bibliothèques d'ancrage/barre d'outils, donc mes outils comme les visionneuses de modèles 3D et les éditeurs de niveau, tous semblaient assez doux.
La plupart des applications que j'ai écrites ont créé l'interface utilisateur par programme, de sorte que l'outil de disposition de boîte de dialogue/fenêtre était plus que suffisant pour mes besoins.
MFC 9 est également très cool, en particulier avec la bibliothèque de contrôle/d'ancrage du ruban que Microsoft a publiée dans le cadre du Feature Pack. Il y a donc encore de la vie chez le vieux chien! :)
Lorsque .net 1.0 est sorti, j'ai trouvé la transition assez facile, car elle supportait le C++ managé. Ce n'était pas joli, mais donnait une rampe d'accès relativement simple au cadre .net. Mais le point de basculement pour moi est venu lorsque j'ai commencé à écrire des outils qui nécessitaient davantage le Concepteur Windows Forms, à l'époque de .net 2.0. J'ai décidé de recommencer et d'apprendre le C #, ce que j'ai adoré - même si je ne m'habituerai jamais à avoir new () sans delete ();). J'ai ensuite commencé à écrire des contrôles utilisateur, trouvant l'expérience très agréable et simple. Le framework .net était énorme, bien pris en charge, et généralement je trouvais plus facile de faire à peu près tout dans C # /. Net. De plus, la compilation était rapide comme l'éclair et la possibilité de refactoriser dans Visual Studio était géniale.
La beauté de c # /. Net est qu'il ne vous limite pas à simplement écrire en code managé. Vous pouvez toujours utiliser du code non managé, si les performances sont un problème par exemple, ou si vous devez partager du code entre les plates-formes. Par exemple, mes bibliothèques mathématiques sont écrites en C/C++, que je mets dans une bibliothèque permettant à C # d'envelopper/utiliser le même code, bien que ce ne soit que temporaire. Je vais aussi porter ces bibliothèques en C # à temps, donc tout est pur .net.
La dernière expérience que je veux mentionner est que j'ai passé les derniers mois loin de la programmation de jeux sur console et passé du temps à programmer l'InterWeb. J'ai utilisé la pile Microsoft, la programmation dans ASP.net/C#, et je dois dire que c'est très agréable, avec toutes les connaissances de C # directement applicables. La seule courbe d'apprentissage était ASP.net, pas la langue et les bibliothèques de support. Avec l'arrivée de .net 3.5 (LINQ est doux) la vie dans le framework .net avec C # est belle.
Quoi qu'il en soit, je ne veux pas transformer cela en histoire de ma vie, mais je voulais juste donner une brève expérience de quelqu'un qui a traversé toutes les technologies dont vous avez parlé. Je voudrais également mentionner qu'il est bon pour vous d'essayer différents langages/cadres. Je code pour l'iPhone depuis un an maintenant, et j'ai vraiment aimé Objective-C. C'est toute la programmation, et c'est tout bon.
En ce qui concerne MFC/.net, les deux ont leurs avantages et leurs inconvénients, et cela ne me dérange vraiment pas du tout, mais pour ce qui est d'aller de l'avant, je m'en tiendrai probablement à C # /. Net, mais s'il vous plaît, s'il vous plaît, s'il vous plaît comprendre comment cela fonctionne. La seule chose que je dirai est de comprendre comment fonctionne la mémoire dans .net, même si `` tout est pris en charge pour vous '';)
Votre connaissance de C/C++ devrait être complètement indépendante du fait que vous utilisiez MFC ou non, c'est toujours un langage critique (en particulier dans la programmation de jeux vidéo sur console), mais pour la programmation d'applications de bureau sur Windows, il devient de plus en plus difficile de contester .net. C'est rapide, facile, a un excellent support d'outils, d'excellentes bibliothèques tierces, une énorme communauté en croissance, est maintenant multiplateforme (Mono) et vous permettra de passer de toutes les technologies Microsoft actuelles/émergentes (ASP.net, WPF, Silverlight, WCF etc).
Pour tout cela, cependant, j'ai toujours configuré Visual Studio en tant qu'environnement C++. Certaines habitudes ne meurent jamais;)
MFC et .NET sont à des extrêmes presque opposés, chacun complètement merdique à sa manière.
L'utilisation du MFC est à peu près de l'ordre de vivre dans l'épave en décomposition d'un bâtiment excédentaire de la Seconde Guerre mondiale. Il n'y a aucun signe pour avertir des zones dangereuses, et il n'est probablement pas immédiatement évident où trouver de l'eau courante, de l'électricité ou des toilettes qui fonctionnent - même si elles sont toutes là, si vous savez comment les trouver. Comme tout bâtiment en décomposition, il y a beaucoup de trous dans les murs et ainsi, vous pouvez donc partir à tout moment aussi longtemps que vous le souhaitez. De même, faire glisser des objets du monde extérieur est assez facile, mais c'est à vous de faire le "glisser" pour y arriver.
Utiliser .NET, c'est comme vivre sur l'ensemble de The Truman Show. Cela correspond à l'idée d'une personne de ce qu'est la vraie vie devrait être. À l'intérieur de ses frontières, la vie peut sembler utopique. En fin de compte, cependant, ce n'est guère plus qu'une cellule de prison agréablement habillée, et rien de ce qu'elle décrit comme la vie n'est bien réel. Toute votre interaction avec le monde extérieur est soumise au caprice d'un réalisateur dont les objectifs sont principalement d'améliorer ses propres cotes; votre bien-être n'est pris en compte que dans la mesure où il l'affecte.
Contrairement à la plupart des prisons, .NET a une voie d'évacuation bien indiquée (étiquetée "P/Invoke"). Comme la voie d'évacuation de toute bonne prison, cependant, c'est un tuyau d'égout d'un kilomètre de long. La plupart des résidents sont conscients de son existence, mais presque les seuls qui y vont sont des adolescents prouvant leur virilité. Les rares personnes qui l'utilisent réellement ne le font qu'en cas de nécessité absolue. Ceux d'entre nous qui ont jugé nécessaire une fois de trop ont réalisé qu'il valait mieux rester dehors et ne pas rentrer.
Edit: Étant donné que certaines personnes veulent que des cercles et des flèches et un paragraphe à l'arrière de chacun soient utilisés comme preuves devant les tribunaux: la force et la faiblesse du MFC est qu'il s'agit principalement d'un emballage assez mince autour de l'API. C'est une faiblesse car il y a un bon nombre de trous dans sa couverture, et parce qu'elle fait relativement peu pour "lisser" les endroits où l'API elle-même ne s'assemble pas particulièrement bien. Par exemple, si quelque chose est implémenté à l'aide de COM, cela apparaîtra généralement directement dans votre code qui l'utilise. C'est une force, car il est assez facile d'étendre MFC pour gérer les zones qu'il ne gère pas par défaut, ainsi que de le contourner simplement et de travailler directement avec l'API lorsque vous en avez besoin. Il a également été mis à jour relativement rarement, alors même s'il peut actuellement produire des applications d'aspect raisonnablement "moderne", cela n'a pas toujours été le cas. Compte tenu de son histoire, il serait difficile de prédire que cela continuera d'être le cas.
La force et la faiblesse de .NET est qu'il s'agit d'un emballage beaucoup plus "épais" autour de l'API. Il fait beaucoup plus pour "atténuer" les différences dans l'API, donc (par exemple) les parties implémentées dans COM ne sont pas/agissent sensiblement différentes des parties implémentées comme des appels de fonction C. De l'intérieur de .NET, les différences disparaissent. .NET est (actuellement) la technologie préférée de Microsoft, il est donc mis à jour beaucoup plus régulièrement et fait un bien meilleur travail pour s'assurer que votre interface utilisateur respecte les dernières directives. Je suppose qu'il est beaucoup plus probable que MFC de continuer à le faire pendant un certain temps.
La faiblesse de .NET est qu'il est beaucoup plus difficile de contourner ou d'étendre. Fondamentalement, votre seul itinéraire vers le monde extérieur est via P/Invoke. Même pour de petites excursions, c'est moche et douloureux. Essayer de l'utiliser très souvent ou pour tout ce qui approche d'une extension majeure est un exercice de masochisme.
Si (presque) tout ce que vous écrivez peut correspondre à ce que .NET prend en charge, c'est le choix évident. Il est beaucoup plus propre et plus lisse tant que vous restez à l'intérieur de ses limites.
Si vous écrivez du code qui doit assez fréquemment sortir des limites prises en charge par le framework, MFC fonctionnera probablement beaucoup mieux pour vous. Avec .NET, le modèle .NET s'applique à votre programme entier. Avec MFC, il est relativement facile d'écrire des programmes qui utilisent MFC pour leur interface utilisateur et de faire les choses comme ils le souhaitent pour tout ce que MFC ne prend pas en charge.
Je pense qu'il est utile de connaître le C++, car le langage durera longtemps. Vous ne savez jamais quand la programmation en C++ peut être requise, et sur le marché du travail d'aujourd'hui, avoir plus de langages à votre actif ne fait qu'améliorer votre CV.
Quant à MFC , je fais de mon mieux pour m'en éloigner. Il est ancien par rapport aux normes informatiques (approchant les 20 ans, je pense), mais Microsoft voit toujours l'intérêt de le prendre en charge avec de nouvelles versions et packs de fonctionnalités. De ce point de vue, je doute que le MFC disparaisse de sitôt. Mais cela ne signifie pas que je veux programmer avec. La fluidité et la facilité avec lesquelles on peut programmer en C # bat le pantalon du MFC/C++ tous les jours de la semaine. Threading, sockets, manipulation de chaînes, etc. - toutes ces choses sont tout simplement plus faciles à faire en C # qu'en C++. De plus, C # /. NET est le principal objectif technologique de Microsoft, et je préfère être sur cet Edge que le backburner MFC en matière de développement de carrière.
Quel est le problème que vous cherchez à résoudre? Supposons que vous connaissiez à la fois C++/MFC et C # /. NET. Quel ensemble d'outils vous permettrait de mieux construire et maintenir? (Mieux est subjectif, mais encore une fois cela dépend de vos objectifs)
À moins que je fasse beaucoup de travail avec des API natives qui ne sont pas disponibles dans .NET, j'irai de loin avec .NET. C++ est un excellent langage et rien ne vous empêche de coder en C++ managé afin de conserver le framework .NET et la gestion de la mémoire.
En comparaison, mon observation est que le framework MFC est très compliqué et peu maniable par rapport aux formulaires Windows .NET.
Une fonctionnalité intéressante que MFC fournit est le cadre Document/View (document unique ou documents multiples) qui n'avait pas encore l'équivalence dans .NET. Cette fonctionnalité peut être très utile et pratique lorsque vous devez créer une application qui fonctionne comme Word de Microsoft. Il permet de séparer le modèle de données de la vue que vous souhaitez représenter pour les utilisateurs. Je pense que la plupart des gens passeront définitivement du côté .NET une fois cette fonctionnalité mise en œuvre. (Microsoft y travaille-t-il ou a-t-il au moins l'intention de travailler là-dessus?)
Je suis passé de C++/MFC à C #/WinForms il y a un peu plus d'un an (floraison tardive, je sais;)).
Mis à part les différences de langue, il sera beaucoup plus facile de passer de MFC à WinForms que l'inverse. Je pense qu'il est certainement utile de connaître MFC si vous avez l'intention de maintenir efficacement les applications héritées. Pourtant:
Aurais-je appris le MFC à partir de zéro (compte tenu des technologies existantes)? Non, probablement pas.
Vais-je écrire de nouvelles applications dans MFC? Non, probablement pas.
Les avantages de MFC sont largement compensés par la prise en charge, la flexibilité et la facilité d'utilisation de .NET. Pour ce que c'est, le MFC est superbe, et je suis reconnaissant d'avoir l'opportunité d'avoir travaillé avec - il m'a appris un beaucoup. En fin de compte, cependant, il est sur le point de disparaître.
Il y a beaucoup d'avantages/inconvénients dans ce choix. MFC est l'ancien stand by, il existe depuis des siècles et montre son âge. En revanche, il est toujours assez bien pris en charge et MS continue de le mettre à jour pour rester à jour.
Le framework .Net a un meilleur support car il a une plus grande équipe qui le soutient et est considéré comme quelque chose sur lequel construire de nouvelles parties de Windows.
D'un autre côté, MFC est une grande partie de l'écosystème Windows. Si vous programmez sur la plate-forme, cela vaudra la peine d'avoir au moins une connaissance pratique de ce que fait MFC et comment le faire lorsque vous finirez par prendre en charge une application MFC (et ne vous inquiétez pas, un jour vous le ferez), vous aurez avoir une bonne base sur où commencer.
Le code non managé ne s'exécute pas nécessairement plus rapidement, il dépend du code écrit et de celui qui écrit le code. J'ai lu des rapports de référence sophistiqués (source, Code Project), et C # a battu C++ à certains égards, C++ a gagné à d'autres. Cela dépend de votre domaine: j'écris des logiciels pour Flight Simulators, donc j'ai besoin d'un environnement non managé. Si vous créez une application graphique, C # peut être le meilleur choix. Pour la programmation de socket à levier bas, C++ peut renvoyer de meilleurs résultats. Je n'ai remarqué aucune différence de vitesse sérieuse entre C++ et C # dans les opérations normales, mais je suis fan de C++ pour sa portabilité native et de C # pour sa facilité.