c# - プログラムによる WPF GUI の C# と F# の比較

Question

エンタープライズ ソフトウェア開発における F# と C# の使用について、どこに線を引くかを決めようとしています。数学コードの F# は非常に簡単です。GUI デザイナーのサポートが不足していても、GUI の作業には F# が好きですが、もちろん、業界では C# GUI 担当者の方がリソースを利用できます。ただし、C#+XAML GUI 開発にはあまり詳しくないので、バイアスが入るのが気になります。

1 つのクライアントの場合、非常に静的な (毎年変更される) 多数の類似の GUI と、非常に動的な他のいくつかの GUI (ビジネス ルール エンジンなど) があります。彼らはすでに F# コードを公開しており、F# のトレーニングにも既に投資しているため、スキルを利用できるかどうかは問題ではありません。私の印象では、C#+XAML を使用すると静的 GUI (いくつかのスライダー、いくつかのテキスト ボックスなど) を簡単に作成できますが、GUI デザイナーがビジネス ルール エンジンのようなプログラムによる GUI でどのように役立つかわかりません。ほとんど静的な GUI のバッテリを維持する (たとえば、100 個の個別の GUI に新しいフィールドを追加する) には手作業が必要になると考えてよいでしょうか? また、

Answer 1

私は C# と F# での GUI プログラミングと非 GUI プログラミング、仕事と遊び、重いプログラムと静的なプログラミングをかなり行ってきました...そして、あなたが述べた印象は正確で実用的だと思います。(私は WPF よりも WinForms に精通していますが、ここではその違いは重要ではないと思います)。

私の印象では、C#+XAML を使用すると静的 GUI (いくつかのスライダー、いくつかのテキスト ボックスなど) を簡単に作成できますが、GUI デザイナーがビジネス ルール エンジンのようなプログラムによる GUI にどのように役立つかわかりません。

これは完全に私の経験です。ほとんどが静的な GUI の場合、C# で WinForms デザイナーを使用することを好みます。ツールの組み合わせは、これらのシナリオに最適であり、F# を使用してデザイナーを使用せずに GUI をハンド コーディングするよりも生産性が高くなります (今、デザイナーで F# がサポートされていれば、私は迷わずそれを好むでしょう)。I'm Only Restingは、純粋な F# よりも C# と WinForms デザイナーを好んだ例です。

また、プログラムによる重い GUI の場合は、デザイナーとプログラムの両方を半分にしようとするよりも、デザイナーを完全に避けるのが最善であると私は信じています (非常に面倒で、非常に速くなります)。したがって、これらのケースでは、F# の方がより表現力のある言語であることは誰もが知っているので、間違いなく F# で GUI をハンドコーディングすることを好みます ;) FsEyeは、WinForms デザイナーで C# よりも純粋な F# を好む例です。

ほとんど静的な GUI のバッテリを維持する (たとえば、100 個の個別の GUI に新しいフィールドを追加する) には手作業が必要になると考えてよいでしょうか?

おそらく。この問題は非常に大きな問題であるため、すぐに解決できる解決策があるとは思えません。ただし、ソフトウェア スイートに適したカスタム ソリューションを構築するためのベスト プラクティスがいくつかあるかもしれません。

また、GUI デザイナーは、プログラムの多い GUI のコンテキストではほとんど役に立たないので、ビジネス ルール エンジンのようなものは、GUI デザイナーをほとんど使用せずに、主に C#+XAML で記述されると考えるのは正しいでしょうか?

はい、最初に言ったように、GUI デザイナーとプログラムによる GUI プログラミングを混同するべきではないと私は信じています。

Answer 2

私は最近、純粋に F# と WPF を使用して有向グラフ視覚化アプリケーションを構築しました。

「プログラムによる」GUI パーツについては、基本的に、データ バインディングと MVVM で操作できる WPF カスタム コントロールを作成しました。

静的部分については、すぐに使用できるカスタム WPF コントロールで XAML を使用しました。

MVVM バインディングには、FSharpX WPF Type Provider を広範囲に使用しました。

そして、この「本」は、始めるのにかなり役立ちました。http://wpffsharp.codeplex.com/

F# と WPF では自然に発生しないものもありますが、ほとんどの場合、合理的に洗練された解決策が見つかりました。一部の WPF データ バインディング文字列は大きくなり、扱いにくくなりました。

Answer 3

質問に正確に答える方法がわからないので、把握するのが少し難しいので、0.05ドルを差し上げます。

優れた MVVM (FP ランドの影響を受ける Rx バージョンさえあります) を使用して WPF を実行すると、コード ビハインド (またはほとんどなし) を作成しなくなります。すでに問題なく WPF-F# アプリケーションを作成できます (デザイナーのサポートも問題ありません。可能であれば BLEND を使用してください。そうでない場合でも、GUI をダムの C# ライブラリに分離できます)。

それでは、ほとんどの GUI を 100% F# で作成しないのはなぜでしょうか?

正直なところ、リファクタリングと ReSharper のようなツールが不足しているためです。現在、VS/R#er にはおかしなサポートがないため、F# のシンボルや型を検索できないのが残念です。

奇妙ですが、Viewmodels の多くの些細なコードを作成する必要がある MVVM コードを記述することは、適切なツールを使用して C# で実行する方が簡単なようです (たとえば、R#er を構成して、公開プローブのすべてのコードを挿入することができます)。内部フィールドに基づいてプライベート/パブリック セッターと INotifyPropertyChanged を使用すると、適切なオプションを選択するだけで、多くの非常に愚かなコードが生成されますが、F# で実行できるよりもはるかに高速です)。

Answer 4

ここには、紛らわしい答えと解決策がたくさんあります。F# と C# はソリューションで組み合わせることができます。C# で GUI を管理し、F# でパッケージを管理します。また、XAML と WinForms の比較は簡単です。XAML を使用すると、コード ビハインドが必要なあらゆることを実行できる十分なスペースがあります。WinForms を使用している場合は、すぐに使用を中止する必要があると思います。たとえば、WPF は、WinForms よりはるかに優れた GUI オプションを備えており、はるかに柔軟で非常に強力です。XAML のバインド機能は言うまでもありません。XAML は静的ですが、コード ビハインドとうまく通信し、あらゆる .NET 言語と通信できます。F# を使用し、C# を一緒に使用して、確実に WinForms の世界から永遠に離れてください。ここに私が行った小さなプロジェクトがあります。WPF、Silverlight、WCF、F#、C#、および VB.NET の組み合わせのみを使用します。WinForms は よく見てみると、WinForms でこれを実現するにはかなりの時間を要したことがわかります。1 つの言語だけでこれを完了することもできましたが、状況によってはスワッピングで時間を節約できましたが、前に進むだけで後戻りすることはありませんでした。WinForms および他のすべてのレガシー オプションは無視され、使用されることはありませんでした。