C # vs F # pour les interfaces graphiques WPF programmatiques

Question

Je suis en train de décider où tracer la ligne sur l'utilisation de F# et C# dans le développement de logiciels d'entreprise. F# pour les mathématiques code est un no-brainer. J'aime F# l'interface de travail, même si elle manque de GUI designer de soutien, mais, bien sûr, il n'y a plus de disponibilité de la ressource de C# GUI de gens dans l'industrie. Cependant, je ne suis pas trop familier avec le C#+XAML développement du GUI, donc je suis préoccupé par un biais.

Dans le cas d'un client, ils ont des dizaines de semblables d'Interfaces graphiques qui sont assez statique (changé chaque année) et quelques autres Interfaces qui sont très dynamiques (par exemple, les règles d'affaires des moteurs). Ils ont déjà le code F# vivent et sont déjà en train d'investir en F#, de la formation afin de compétences de la disponibilité n'est pas un problème. Mon impression est que C#+XAML, vous permet de créer statique des Interfaces graphiques (quelques curseurs, quelques zones de texte, etc.) facilement, mais je ne vois pas comment le GUI designer aiderait les programmes d'Interfaces graphiques comme un moteur de règles. Suis-je en droit de penser que le maintien d'une batterie de la plupart statique des Interfaces graphiques (p. ex. l'ajout d'un nouveau champ à 100 Gui) nécessitera un travail manuel? Aussi, suis-je en droit de penser que le GUI designer est de peu d'utilité dans le contexte de fortement Interfaces programmatiques donc quelque chose comme un moteur de règles serait écrit principalement en C#+XAML avec peu d'utilisation de l'interface graphique designer?

Answer 1

J'ai fait une bonne quantité de GUI et de la non-GUI programmation en C# et F#, dans le travail et le jeu, lourds des programmes et de la statique... et je crois que votre impression est précise et pratique. (notez que je suis plus familier avec les WinForms qu'avec WPF, mais je ne pense pas que les différences d'importance ici).

Mon impression est que C#+XAML, vous permet de créer statique des Interfaces graphiques (un peu curseurs, quelques zones de texte, etc.) facilement, mais je ne vois pas comment le GUI concepteur devrait aider les programmes d'Interfaces graphiques comme une entreprise de règles moteur.

C'est absolument mon expérience. Pour la quasi-statique des Interfaces graphiques, je préfère utiliser les WinForms designer avec C#. L'outillage combo est idéal pour ces scénarios, et il est plus productif de la main-codage de l'interface graphique avec F# et aucun concepteur (maintenant, si il n'y avait F# prise en charge avec le concepteur, je n'aurais aucune hésitation préférant que). Je ne suis de Repos est un exemple où j'ai préféré C# avec les WinForms concepteur de la plus pure F#.

Et pour lourds programmatique des Interfaces graphiques, je crois qu'il est préférable d'éviter le concepteur tout à fait, plutôt que d'essayer d'aller la moitié du concepteur de la moitié programmatique (il devient réel désordre, très rapide). Donc dans ces cas, je préfère largement la main-codage de l'Ihm en F#, puisque tout le monde sait que F# est le plus expressif de la langue ;) FsEye est un exemple où j'ai préféré pure F# C# avec les WinForms designer.

Suis-je en droit de penser que le maintien d'une batterie de essentiellement statiques Les interfaces graphiques (p. ex. l'ajout d'un nouveau champ à 100 Gui) nécessitera le travail manuel?

Probablement. Je ne crois pas qu'il n'y a vraiment aucune solution pour ce problème car il est vraiment tout à fait un grand. Mais il peut y avoir un certain nombre de meilleures pratiques pour créer une solution personnalisée à droite de votre suite de logiciels.

Aussi, suis-je en droit de penser que le GUI designer est de peu d'utilité dans le contexte de fortement Interfaces programmatiques donc quelque chose comme une entreprise moteur de règles serait écrit principalement en C#+XAML avec peu d'utilisation de le GUI designer?

Oui, comme je l'ai dit plus tôt, il est ma conviction que vous ne devriez pas essayer de mélanger le GUI designer avec de lourdes programmatique de la programmation GUI.

Answer 2

J'ai récemment construit un graphe orienté application de visualisation à l'aide purement F# et WPF.

Pour le programmatiques' GUI de pièces, j'ai essentiellement construit WPF contrôles personnalisés que je pouvais être avec la liaison de données et de MVVM.

Pour les éléments statiques j'ai utilisé le XAML avec out-of-the-box et personnalisé des contrôles WPF.

J'ai utilisé le FSharpX WPF Type de Fournisseur largement pour MVVM de liaison.

Et ce livre m'a aidé un peu pour commencer. http://wpffsharp.codeplex.com/

Certaines choses ne viennent pas naturellement avec F# et WPF, mais dans presque tous les cas, un assez élégant solution a été trouvée. Certains WPF liaison de données de chaînes de caractères ne sont volumineuses et lourdes.

Answer 3

Je ne sais pas exactement comment répondre à la question c'est un peu dur à mettre la main à la donc je vous donne juste mon 0.05$:

Si vous ne WPF avec une bonne MVVM (il y a même des Rx-Versions qui sont influencées par des FP-terre) vous ne pouvez pas écrire de code-behind (ou presque rien) - et avec WPF par type de fournisseurs et de tous les autres grands trucs qui sont autour de vous pouvez déjà écrire WPF-F# applications sans aucun problème (même prise en charge du concepteur n'est pas un problème - il suffit d'utiliser le MÉLANGE si vous pouvez - si vous pouvez encore séparée de l'interface graphique dans un muet C#-lib.)

alors pourquoi ne pas écrire la plupart des Interfaces graphiques en 100% F# alors?

Eh bien, pour être honnête... c'est le manque de refactoring et des outils comme ReSharper - c'est juste frustrant que je ne peut pas rechercher F#-des symboles ou des types, car il n'est pas foutu de soutien dans VS/R#er dès maintenant.

C'est étrange, mais l'écriture du MVVM code où vous avez à créer beaucoup de trivial code pour votre Viewmodel semble être plus facile de le faire en C# avec les bons outils en ce moment (par exemple: je peux configurer R#er à insérer de moi tout le code pour le public probertys privé/public, organismes de normalisation et de INotifyPropertyChanged basé sur des champs juste en pressant et en choisissant la bonne option - cela va générer beaucoup de très bête de code, mais c'est beaucoup plus rapide que vous pourriez faire en F#)

Answer 4

Comme vous l'avez souligné, F# est beaucoup plus rare de compétences parmi les programmeurs en général dans l'industrie de l'informatique, alors que chaque homme et son chien sait C# (ou Java, C/C++ qui se transmet à travers).

Ainsi, à partir de purement d'un point de vue managerial il a probablement fait plus de sens pour aller avec C#+XAML F# en raison d'un certain nombre de facteurs:

1. Programmeur de salaires à l'embauche d'un F# gourou ajoute un peu le budget salarial
2. Temps de développement - ce qui pourrait être soutenu de toute façon voir 1 pour une bonne comparaison
3. Le risque de l'utilisation de F# augmente considérablement le facteur de risque dans chacune des catégories:
   • Programmeur feuilles de l'entreprise et prend de la propriété intellectuelle avec eux
   • Programmeur feuilles de la société et elle ne peut pas embaucher un remplaçant => projet manque la date limite
   • Société n'ont pas suffisamment de mesures disponibles pour évaluer le temps requis pour le projet
   • La langue devient depracated et le code doit être porté (pas une grande préoccupation, mais encore plus à risque que C#)
   • Etc. etc.

Cependant, d'un point de vue technique, F# (peut-être avec un add-on de la bibliothèque pour des visualisations) est en mesure de simplement générer une puissante interface graphique. C#, cependant, a aussi cette capacité - vous pouvez générer l'ensemble de votre interface graphique sans utiliser XAML par programmation.

Comme pour l'ajout d'un nouvel élément à 100+ Ihm, ici, je ne vois pas comment XAML est un désavantage à tous. Si je comprends votre question correctement, vous pouvez utiliser un Modèle de Données qui vous pouvez mettre à jour une fois dans le code XAML pour que le changement se propager à travers tous vos Interfaces graphiques.

En conclusion, je vous dirais que, sauf si vous avez une bonne raison de l'utilisation de F#, bâton avec C# car elle permettra de réduire les risques pour votre entreprise dans le long terme.

Answer 5

Je vois beaucoup de confusion des réponses et des solutions ici. F# et C# peuvent être combinés dans la solution. Laissez-C# gérer l'interface graphique et F# gérer les packages. Aussi, XAML vs WinForms est pas sorcier. Avec XAML, Il n'y a plus assez de place pour le code derrière pour faire tout et de tout ce dont vous avez besoin. Si vous utilisez WinForms alors je crois que vous avez besoin de prendre sa retraite immédiatement. WPF par exemple, est beaucoup plus souple et extrêmement puissant avec une interface graphique options de loin supérieurs à ceux de WinForms. Pour ne pas mentionner la force contraignante de XAML. XAML est statique, mais communique avec le code derrière tout bien et qu'il peut communiquer à toute et à tous .NET languages. L'utilisation de F#, utiliser le C#, ensemble, et de quitter définitivement le monde des WinForms pour toujours. Voici un petit projet que j'ai fait. Il utilise uniquement un combinatin de WPF, Silverlight, WCF, F#, C#, et VB.NET. WinForms n'était pas touché, et si vous regardez attentivement, vous verrez que y parvenir, ce avec WinForms aurait pris les âges. Je pourrais avoir terminé avec seulement une langue, mais la permutation a contribué à sauver du temps en fonction de la situation, mais je ne suis allé de l'avant, jamais en arrière. WinForms ainsi que toutes les autres options héritées ont été ignorés et n'est jamais utilisé.