プログラムによるWPFGUIのC＃とF＃
エンタープライズソフトウェア開発でのF＃とC＃の使用についてどこに線を引くかを決めようとしています。数学コードのF＃は簡単です。 GUIデザイナーのサポートがないにもかかわらず、GUI作業用のF＃が好きですが、もちろん、業界ではC＃GUIの人々のリソースの可用性が高くなっています。ただし、私はC＃+ XAML GUI開発にあまり精通していないため、バイアスの導入について懸念しています。
1つのクライアントの場合、非常に静的な（毎年変更される）数十の同様のGUIと、非常に動的な他のいくつかのGUI（ビジネスルールエンジンなど）があります。彼らはすでにF＃コードを公開しており、すでにF＃トレーニングに投資しているため、スキルの可用性は問題になりません。私の印象では、C＃+ XAMLを使用すると静的GUI（いくつかのスライダー、いくつかのテキストボックスなど）を簡単に作成できますが、GUIデザイナーがビジネスルールエンジンのようなプログラマティックGUIをどのように支援するかわかりません。ほぼ静的なGUIのバッテリーを維持する（たとえば、100個の個別のGUIに新しいフィールドを追加する）には手作業が必要になると私は考えていますか？また、GUIデザイナは高度にプログラムされたGUIのコンテキストではほとんど役に立たないので、ビジネスルールエンジンのようなものは主にC＃+ XAMLで記述され、GUIデザイナはほとんど使用されないと思いますか？
私は、C＃とF＃で、仕事と遊びで、プログラマティックで静的な重いGUIプログラミングと非GUIプログラミングを大量に行ってきました...そして、あなたの述べた印象は正確で実用的だと思います。 （私はWPFよりもWinFormsに精通していますが、ここでは違いは重要ではないと思います）。
私の印象では、C＃+ XAMLを使用すると静的GUI（いくつかのスライダー、いくつかのテキストボックスなど）を簡単に作成できますが、GUIデザイナーがビジネスルールエンジンのようなプログラマティックGUIをどのように支援するかわかりません。
これは絶対に私の経験です。ほとんど静的なGUIの場合、C＃でWinFormsデザイナーを使用することを好みます。ツールコンボはこれらのシナリオに最適であり、F＃を使用してデザイナーなしでGUIを手動でコーディングするよりも生産性が高くなります（デザイナーによるF＃サポートがあれば、それを好むことをためらうことはありません）。 I'm Only Resting は、純粋なF＃よりもWinFormsデザイナーでC＃を優先した例です。
また、プログラマティックGUIが重い場合は、デザイナーの半分をプログラマティックにしようとするよりも、デザイナーを完全に避けるのが最善だと思います（非常に面倒で、非常に速くなります）。したがって、これらの場合、F＃がより表現力豊かな言語であることを誰もが知っているので、私は間違いなくF＃でGUIを手動でコーディングすることを好みます;） FsEye は、WinFormsデザイナーでC＃よりも純粋なF＃を好んだ例です。
ほぼ静的なGUIのバッテリーを維持する（たとえば、100個の個別のGUIに新しいフィールドを追加する）には手作業が必要になると私は考えていますか？
恐らく。それは本当にかなり大きいので、私はこの問題の準備ができている解決策が本当にあるとは思わない。ただし、ソフトウェアスイートに適したカスタムソリューションを構築するためのベストプラクティスがいくつかあるかもしれません。
また、GUIデザイナは高度にプログラムされたGUIのコンテキストではほとんど役に立たないので、ビジネスルールエンジンのようなものは主にC＃+ XAMLで記述され、GUIデザイナはほとんど使用されないと思いますか？
はい、前に言ったように、GUIデザイナーと重いプログラムによるGUIプログラミングを混ぜてはいけないと私は信じています。
私は最近、純粋にF＃とWPFを使用して有向グラフ視覚化アプリケーションを構築しました。
「プログラマティック」GUIパーツについては、基本的に、データバインディングとMVVMで操作できるWPFカスタムコントロールを構築しました。
静的パーツには、すぐに使用できるカスタムWPFコントロールを備えたXAMLを使用しました。
私は、MVVMバインディングにFSharpXWPFタイププロバイダーを広範囲に使用しました。
そして、この「本」は私が始めるのにかなり役立ちました。 http://wpffsharp.codeplex.com/
F＃とWPFには自然に付属しないものもありますが、ほとんどの場合、かなりエレガントなソリューションが見つかりました。一部のWPFデータバインディング文字列は大きくなり、扱いにくくなりました。
質問に正確に答える方法がわからないので、把握するのがやや難しいので、0.05ドルを差し上げます。
優れたMVVM（FP-landの影響を受けるRxバージョンもあります）を使用してWPFを実行する場合、コードビハインド（またはほとんどなし）を記述せず、WPFタイププロバイダーやその他すべての優れた機能を使用します。あなたの周りではすでに問題なくWPF-F＃アプリケーションを書くことができます（デザイナーのサポートでも問題ありません-できればBLENDを使用してください-そうでない場合でもGUIをダムC＃-libに分離できます）。
では、なぜほとんどのGUIを100％F＃で記述しないのでしょうか。
正直なところ...リファクタリングとReSharperのようなツールがないことです-現在VS/R＃erにはおかしなサポートがないため、F＃の記号やタイプを検索できないのはイライラします。
奇妙ですが、Viewmodelの多くの些細なコードを作成する必要があるMVVMコードの記述は、現在、適切なツールを使用してC＃で行う方が簡単なようです（たとえば、パブリックプローブのすべてのコードを挿入するようにR＃erを構成できます）プライベート/パブリックセッターと内部フィールドに基づくINotifyPropertyChangedを使用して、-を押して適切なオプションを選択する-これにより、非常にダムなコードが大量に生成されますが、F＃で実行できるよりもはるかに高速です）
ご指摘のとおり、F＃は一般的なIT業界のプログラマーの間では非常に希少なスキルですが、すべての人と彼の犬はC＃（または、Java、簡単に翻訳できるC/C++）を知っています。
したがって、純粋に管理の観点からは、次のような多くの要因があるため、F＃よりもC＃+ XAMLを使用する方が理にかなっています。
- プログラマーの給与-F＃の第一人者を雇うと、給与予算がかなり増えます
- 開発時間-これはどちらの方法でも議論される可能性があります 1 を参照してください
- 企業リスク-F＃を使用すると、各カテゴリのリスク要因が大幅に増加します：
- プログラマーは会社を辞め、知的財産を持ち帰ります
- プログラマーが会社を辞め、会社は代替品を雇うことができない=>プロジェクトが期限を逃す
- 会社には、プロジェクトに必要な時間を測定するために利用できる適切なメトリックがありません
- 言語は時代遅れになり、コードを移植する必要があります（それほど大きな問題ではありませんが、C＃よりもリスクが高くなります）
- などなど.
ただし、エンジニアリングの観点からは、F＃（おそらく視覚化用のアドオンライブラリを使用）は、強力なGUIを簡単に生成できます。ただし、C＃にもこの機能があります。プログラムでXAMLを使用せずにGUI全体を生成できます。
100以上のGUIに新しいアイテムを追加することに関しては、ここではXAMLがどのように不利であるかはまったくわかりません。私があなたの質問を正しく理解している場合は、XAMLで一度更新して変更をすべてのGUIに伝播させることができるデータテンプレートを使用できます。
結論として、F＃を使用する強い理由がない限り、長期的には会社へのリスクを軽減するため、C＃を使用することをお勧めします。
ここには、紛らわしい答えや解決策がたくさんあります。 F＃とC＃はソリューションで組み合わせることができます。 C＃でGUIを管理し、F＃でパッケージを管理します。また、XAMLとWinFormsは非常に簡単です。 XAMLを使用すると、必要なすべてのことを実行するためのコードの背後に十分な余地があります。 WinFormsを使用している場合は、すぐに廃止する必要があると思います。たとえば、WPFははるかに柔軟で非常に強力であり、GUIオプションはWinFormsのオプションをはるかに上回っています。 XAMLの拘束力は言うまでもありません。 XAMLは静的ですが、コードビハインドとうまく通信し、すべての.NET言語と通信できます。 F＃を使用し、C＃を一緒に使用して、WinFormsの世界を永遠に残してください。これが私が行った小さなプロジェクトです。 WPF、Silverlight、WCF、F＃、C＃、およびVB.NETの組み合わせのみを使用します。 WinFormsには触れていません。よく見ると、WinFormsでこれを実現するには時間がかかっていることがわかります。 1つの言語だけでこれを完了することもできましたが、状況によっては交換することで時間を節約できましたが、後戻りすることはなく、前に進むだけでした。 WinFormsおよび他のすべてのレガシーオプションは無視され、使用されませんでした。