Pérenniser une grande application d'interface utilisateur - MFC avec le pack de fonctionnalités 2008, ou C# et Winforms ?

Question

Mon entreprise a développé un produit de longue date utilisant MFC dans Visual C++ comme standard de facto pour le développement d'interface utilisateur.Notre base de code contient BEAUCOUP de code hérité/archaïque qui doit rester opérationnel.Une partie de ce code est plus ancienne que moi (écrite à l'origine à la fin des années 70) et certains membres de notre équipe utilisent toujours Visual Studio 6.

Cependant, nous sommes heureusement arrivés à la conclusion en interne que notre produit semble quelque peu désuet par rapport à celui de nos concurrents et qu'il faut faire quelque chose.

Je travaille actuellement sur une nouvelle zone de l'interface utilisateur qui est assez distincte du reste du produit.J'ai donc eu la chance d'essayer de « nouvelles » piles de technologies comme une sorte de terrain d'essai avant que le long processus de déplacement sur le reste de l'interface utilisateur ne commence.

J'utilise C# avec Windows Forms et le framework .net depuis un certain temps pendant mon temps libre et j'en profite, mais je suis quelque peu inquiet des maux de tête causés par l'interopérabilité.Bien que cette branche particulière de l'interface utilisateur ne nécessite pas beaucoup d'interopérabilité avec l'ancienne base de code C++, je peux prévoir que cela deviendra un problème à l'avenir.

L'alternative consiste simplement à continuer avec MFC, mais essayez de profiter du nouveau pack de fonctionnalités fourni avec VS2008.Je suppose que c'est l'option la plus simple, mais je m'inquiète de la longévité et de ne pas profiter des avantages qu'est .net...

Alors, lequel choisir ?Nous sommes une petite équipe, donc ma recommandation sera très probablement acceptée comme une orientation future pour notre développement – ​​je veux bien faire les choses.

Le MFC est-il mort ?C#/Winforms est-il la voie à suivre ?Y a-t-il autre chose qui me manque totalement ?Aide grandement appréciée!

Answer 1

Je suis développeur sur une application qui contient une tonne de code MFC existant, et nous avons tous les mêmes préoccupations.L’un des principaux moteurs de notre stratégie était d’éliminer autant de risques et d’incertitudes que possible, ce qui impliquait d’éviter The Big Rewrite.Comme nous le savons tous, TBR échoue la plupart du temps.Nous avons donc choisi une approche incrémentielle qui nous permet de conserver les modules qui ne changeront pas dans la version actuelle, d'écrire de nouvelles fonctionnalités gérées et de porter les fonctionnalités qui font l'objet d'améliorations.

Vous pouvez procéder de plusieurs manières :

1. Hébergez du contenu WPF sur vos vues MFC (voir ici)

2. Pour les applications MFC MDI, créez un nouveau framework WinForms et hébergez vos vues MFC MDI (voir ici)

3. Hébergez les contrôles utilisateur WinForms dans les boîtes de dialogue et les vues MFC (voir ici)

Le problème avec l’adoption de WPF (option 1) est que cela vous obligera à réécrire toute votre interface utilisateur en même temps, sinon cela aura l’air plutôt schizophrène.

La deuxième approche semble viable mais très compliquée.

La troisième approche est celle que nous avons sélectionnée et elle fonctionne très bien.Il vous permet d'actualiser de manière sélective les zones de votre application tout en conservant une cohérence globale et en ne touchant pas aux éléments qui ne sont pas cassés.

Le Feature Pack Visual C++ 2008 semble intéressant, mais je n'ai pas joué avec.On dirait que cela pourrait aider à résoudre votre problème d'apparence obsolète.Si le « ruban » est trop choquant pour vos utilisateurs, vous pouvez vous tourner vers des fournisseurs de contrôles MFC et/ou WinForms tiers.

Ma recommandation globale est que l'interopérabilité + le changement incrémentiel sont définitivement préférables aux changements radicaux.

---

Après avoir lu votre suivi, je peux certainement confirmer que les gains de productivité du framework dépassent largement l'investissement dans son apprentissage.Personne dans notre équipe n'avait utilisé C# au début de cet effort et maintenant nous le préférons tous.

Answer 2

En fonction de l'application et de la volonté de vos clients d'installer .NET (ils ne le sont pas tous), je passerais certainement à WinForms ou WPF.L'interopérabilité avec le code C++ est considérablement simplifiée en refactorisant le code non-UI dans des bibliothèques de classes à l'aide de C++/CLI (comme vous l'avez noté dans votre sélection de balises).

Le seul problème avec WPF est qu’il peut être difficile de conserver l’apparence actuelle.Le passage à WinForms peut être effectué tout en conservant l’apparence actuelle de votre interface graphique.WPF utilise un modèle tellement différent que tenter de conserver la présentation actuelle serait probablement futile et ne serait certainement pas dans l'esprit de WPF.WPF a également apparemment des performances médiocres sur les machines antérieures à Vista lorsque plusieurs processus WPF sont en cours d'exécution.

Ma suggestion est de découvrir ce que vos clients utilisent.Si la plupart ont migré vers Vista et que votre équipe est prête à effectuer beaucoup de travail sur l'interface graphique, je dirais d'ignorer WinForms et de passer à WPF.Sinon, regardez sérieusement WinForms.Dans les deux cas, une bibliothèque de classes en C++/CLI est la réponse à vos préoccupations d'interopérabilité.

Answer 3

Vous ne donnez pas beaucoup de détails sur ce que fait votre code existant ou sur la façon dont il est structuré.Si vous avez certains critères de performances, vous souhaiterez peut-être conserver une partie de votre base de code en C++.Vous aurez plus de facilité à effectuer l'interopérabilité avec votre ancien code s'il est exposé de la bonne manière. Pouvez-vous appeler la base de code existante à partir de C# aujourd'hui ?Cela vaut peut-être la peine de réfléchir à un projet pour mettre en place cette structure.

En ce qui concerne WPF, vous pourriez affirmer que WinForms pourrait être plus approprié.Passer à WinForms est une étape importante pour vous et votre équipe.Peut-être seront-ils plus à l’aise avec le passage à WinForms ?C'est mieux documenté, plus d'expérience sur le marché et utile si vous avez toujours besoin de prendre en charge les clients Windows 2000.

Vous pourriez être intéressé par Extension des applications MFC avec le .NET Framework

Une autre chose à considérer est C++/CLI, mais je n'en ai aucune expérience.

Answer 4

Merci à tous bien vouloir pour vos réponses, c'est rassurant de voir que globalement le consensus suit ma ligne de pensée.J'ai la chance que notre logiciel fonctionne également sur notre propre matériel personnalisé (pour l'industrie de la diffusion) - le choix du système d'exploitation nous appartient donc vraiment et incombe à nos clients.Actuellement, nous utilisons XP/2000, mais je perçois une volonté de passer bientôt à Vista.

Cependant, nous devons également maintenir un contrôle très précis sur les performances du GPU, ce qui, je suppose, exclut automatiquement WPF et l'accélération matérielle ?J'aurais dû le souligner dans mon message d'origine - désolé.Il est peut-être possible d'utiliser deux GPU...mais c'est une tout autre question...

L'équipe n'a pas d'expérience significative en C# et je ne suis pas moi-même un expert, mais je pense que les avantages globaux à long terme d'un environnement géré dépassent probablement le temps qu'il faudra pour se mettre à niveau.

On dirait que Winforms et C# l'ont pour le moment.

Answer 5

Si vous envisagiez de passer à C# et donc à .NET, je considérerais Windows Presentation Foundation plutôt que WinForms.WPF est l'avenir des clients intelligents dans .NET, et les compétences que vous acquerrez, vous pourrez les réutiliser si vous souhaitez créer des applications Silverlight hébergées par un navigateur.

Answer 6

Je suis d'accord avec le sentiment de WPF.L'interface utilisateur basée sur les balises/XML semble être un peu plus portable que WinForms.

Je suppose que vous devez également tenir compte de votre équipe. S'il n'y a pas beaucoup de compétences actuelles en C#, alors c'est un facteur, mais à l'avenir, le marché des développeurs MFC diminue et C# se développe.

Peut-être qu’une sorte d’approche fragmentaire serait possible ?J'ai été impliqué dans le recodage d'applications existantes en C#, et cela prend toujours beaucoup plus de temps que vous ne le pensez, surtout si vous conservez du code existant ou si votre équipe n'est pas très familiarisée avec C#.