C # vs F # pour les interfaces graphiques programmables WPF
J'essaie de décider où tracer la limite sur l'utilisation de F # et C # dans le développement de logiciels d'entreprise. F # pour le code mathématique est une évidence. J'aime F # pour le travail avec une interface graphique, même s’il manque de support pour les concepteurs d’interface graphique, mais, bien sûr, les ressources des personnes disposant d’une interface graphique C # sont plus nombreuses dans l’industrie. Cependant, je ne suis pas trop familier avec le développement de l'interface graphique C # + XAML, je suis donc préoccupé par l'introduction de biais.
Dans le cas d'un client, ils ont des dizaines d'interfaces graphiques similaires, statiques (modifiées chaque année) et quelques autres interfaces graphiques très dynamiques (moteurs de règles métier, par exemple). Ils ont déjà le code F # en direct et investissent déjà dans la formation F # pour que la disponibilité des compétences ne soit pas un problème. Mon impression est que C # + XAML vous permet de construire facilement des interfaces graphiques statiques (quelques curseurs, quelques zones de texte, etc.), mais je ne vois pas comment le concepteur de l'interface graphique pourrait aider les interfaces graphiques programmatiques comme un moteur de règles métier. Ai-je raison de penser que le maintien d'une batterie d'interfaces utilisateur principalement statiques (par exemple, l'ajout d'un nouveau champ à 100 interfaces utilisateur distinctes) nécessitera un travail manuel? De plus, ai-je raison de penser que le concepteur d'interface graphique est peu utile dans le contexte d'interfaces graphiques fortement programmatiques, de sorte que quelque chose comme un moteur de règles métier serait écrit principalement en C # + XAML avec peu d'utilisation du concepteur d'interface graphique?
J'ai effectué une bonne quantité de programmation avec et sans interface graphique en C # et F #, au travail et dans les loisirs, avec une programmation lourde et statique ... et je crois que votre impression déclarée est exacte et pratique. (Notez que je connais mieux WinForm que WPF, mais je ne pense pas que les différences importent ici).
Mon impression est que C # + XAML vous permet de créer facilement des interfaces utilisateur graphiques statiques (quelques curseurs , Quelques zones de texte, etc.), mais je ne vois pas comment le concepteur de l'interface graphique Pourrait vous aider avec des interfaces utilisateur programmatiques telles que un moteur de règles métier .
C'est absolument mon expérience. Pour les interfaces graphiques principalement statiques, je préfère utiliser le concepteur WinForms avec C #. La combinaison d'outils est idéale pour ces scénarios et est plus productive que le codage manuel de l'interface graphique avec F # et aucun concepteur (maintenant, s'il y avait un support F # avec le concepteur, je n'aurais aucune hésitation à le préférer). I'm Only Resting est un exemple où j'ai préféré C # avec le concepteur WinForms à F # pur.
Et pour les interfaces graphiques programmatiques lourdes, je pense qu’il est préférable d’éviter complètement le concepteur, plutôt que d’essayer de passer à la moitié concepteur mi-programmatique (cela devient vraiment désordonné, très rapide). Donc, dans ces cas, je préfère définitivement coder à la main les interfaces graphiques en F #, puisque tout le monde sait que F # est le langage le plus expressif;) FsEye est un exemple où j'ai préféré le pur F # au C # avec le concepteur WinForms.
Ai-je raison de penser que le maintien d'une batterie d'interfaces utilisateur graphiques (Par exemple, l'ajout d'un nouveau champ à 100 interfaces utilisateur distinctes) nécessitera un travail manuel de ?
Probablement. Je ne crois pas qu'il y ait vraiment de solution prête à ce problème car c'est vraiment une très grande. Cependant, il peut exister certaines des meilleures pratiques pour créer une solution personnalisée adaptée à votre suite logicielle.
De plus, ai-je raison de penser que le concepteur d'interface graphique est peu utile dans Dans le contexte d'interfaces graphiques fortement programmatiques, de sorte que quelque chose comme un moteur de règles métier Serait écrit principalement en C # + XAML avec peu utilisation de le concepteur d'interface graphique?
Oui, comme je l’ai dit plus tôt, j’ai la conviction que vous ne devriez pas essayer de mélanger le concepteur d’interface graphique avec une programmation lourde d’interface graphique programmatique.
J'ai récemment construit une application de visualisation de graphe dirigée utilisant purement F # et WPF.
Pour les parties de l'interface graphique «programmatique», j'ai essentiellement construit des contrôles personnalisés WPF que je pouvais utiliser avec la liaison de données et MVVM.
Pour les parties statiques, j'ai utilisé XAML avec des contrôles WPF prêts à l'emploi et personnalisés.
J'ai largement utilisé le fournisseur de types FSharpX WPF pour la liaison MVVM.
Et ce «livre» m'a beaucoup aidé à démarrer. http://wpffsharp.codeplex.com/
Certaines choses ne viennent pas naturellement avec F # et WPF, mais dans presque tous les cas, une solution raisonnablement élégante a été trouvée. Certaines chaînes de liaison de données WPF sont devenues volumineuses et difficiles à manier.
Je ne sais pas comment répondre exactement à la question car il est un peu difficile de s'en procurer, alors je vous donne mon 0.05 $:
Si vous faites WPF avec un bon MVVM (il y a même des versions Rx qui sont influencées par FP-land), vous n'écrirez pas de code-behind (ou presque aucun) - et avec les fournisseurs de types WPF et tous les autres trucs géniaux qui sont Tout autour de vous pouvez déjà écrire des applications WPF-F # sans aucun problème (même l’assistance du concepteur n’est pas un problème - utilisez simplement BLEND si vous le pouvez, sinon vous pouvez toujours séparer l’interface graphique dans une bibliothèque C # idiote.)
alors pourquoi ne pas écrire la plupart des interfaces graphiques en 100% F #?
Pour être honnête, c’est le manque de refactoring et d’outils comme ReSharper. C’est frustrant de ne pas pouvoir rechercher de symboles ou de types F #, car VS/R # ne propose aucun support vraiment inquiétant.
C'est étrange, mais écrire du code MVVM où vous devez créer beaucoup de code trivial pour vos modèles View semble être plus facile à faire en C # avec les bons outils maintenant (par exemple: je peux configurer R # er pour qu'il m'insère tout le code pour les probertys publics avec des setters privés/publics et INotifyPropertyChanged basés sur des champs internes en appuyant simplement - et en choisissant la bonne option - cela générera beaucoup de code très stupide mais c'est beaucoup plus rapide que vous pourriez le faire en F #)
Comme vous l'avez fait remarquer, F # est une compétence beaucoup plus rare chez les programmeurs de l'industrie informatique en général, alors que chaque homme et son chien connaissent C # (ou Java, C/C++, qui se traduisent facilement).
Ainsi, d’un point de vue purement administratif, il est probablement plus logique d’utiliser C # + XAML sur F # en raison d’un certain nombre de facteurs:
- Salaires du programmeur - l'embauche d'un gourou F # ajoute un peu au budget salarial
- Temps de développement - cela pourrait être discuté dans les deux sens voir 1 pour une bonne comparaison
- Risque d'entreprise - l'utilisation de F # augmente considérablement le facteur de risque dans chacune des catégories:
- Le programmeur quitte l'entreprise et emporte avec lui la propriété intellectuelle
- Le programmateur quitte l'entreprise et l'entreprise ne peut pas embaucher de remplaçant => le projet dépasse le délai
- La société ne dispose pas de mesures adéquates pour évaluer le temps requis pour le projet.
- La langue devient obsolète et le code doit être porté (pas une préoccupation aussi importante mais toujours un risque plus élevé que le C #)
- Etc.
Cependant, d’un point de vue technique, F # (peut-être avec une bibliothèque supplémentaire pour les visualisations) est capable de générer simplement une puissante interface graphique. C #, cependant, a également cette capacité - vous pouvez générer votre interface graphique complète sans utiliser XAML par programme.
En ce qui concerne l'ajout d'un nouvel élément à plus de 100 interfaces graphiques, je ne vois pas en quoi le XAML est un désavantage. Si je comprends bien votre question, vous pouvez utiliser un modèle de données que vous pouvez mettre à jour une fois dans XAML et que le changement se répercute sur toutes vos interfaces graphiques.
En conclusion, je vous suggérerais qu'à moins que vous n'ayez une bonne raison d'utiliser F #, restez avec C # car cela réduirait les risques pour votre entreprise à long terme.
Je vois beaucoup de réponses et de solutions déroutantes ici. F # et C # peuvent être combinés en solution. Laissez C # gérer l’interface graphique et F # les packages. En outre, XAML vs WinForms est une évidence. Avec XAML, il y a largement assez de place pour que le code derrière puisse faire tout ce dont vous avez besoin. Si vous utilisez WinForms, je pense que vous devez prendre votre retraite immédiatement. WPF, par exemple, est beaucoup plus flexible et extrêmement puissant avec des options d'interface graphique bien supérieures à celles de WinForms. Sans parler du pouvoir contraignant de XAML. XAML est statique mais communique bien avec le code derrière et peut communiquer avec tous les langages .NET. Utilisez F #, utilisez C # ensemble et quittez définitivement le monde de WinForms. Voici un petit projet que j'ai fait. Il utilise uniquement une combinaison de WPF, Silverlight, WCF, F #, C # et VB.NET. WinForms n'a pas été touché et si vous y regardez de plus près, vous constaterez que cela aurait pris du temps avec WinForms. J'aurais pu le faire avec une seule langue, mais la permutation permettait de gagner du temps en fonction de la situation, mais je n'avais fait que progresser, jamais en arrière. WinForms ainsi que toutes les autres options héritées ont été ignorés et jamais utilisés.