用于编程 WPF GUI 的 C# 与 F#

C# vs F# for programmatic WPF GUIs

提问by Jon Harrop

I'm trying to decide where to draw the line on the use of F# and C# in enterprise software development. F# for mathematical code is a no-brainer. I like F# for GUI work even though it lacks GUI designer support but, of course, there is more resource availability of C# GUI people in industry. However, I am not too familiar with C#+XAML GUI development so I'm concerned about introducing bias.

我正在尝试确定在企业软件开发中使用 F# 和 C# 的界限。用于数学代码的 F# 是轻而易举的。我喜欢 F# 的 GUI 工作，尽管它缺乏 GUI 设计器的支持，但是，当然，工业中的 C# GUI 人员有更多的资源可用。但是，我对 C#+XAML GUI 开发不太熟悉，所以我担心引入偏见。

In the case of one client, they have dozens of similar GUIs that are quite static (changed yearly) and a few other GUIs that are very dynamic (e.g. business rules engines). They already have F# code live and are already investing in F# training so skills availability isn't an issue. My impression is that C#+XAML let you build static GUIs (a few sliders, a few text boxes etc.) easily but I cannot see how the GUI designer would help with programmatic GUIs like a business rules engine. Am I right in thinking that maintaining a battery of mostly-static GUIs (e.g. adding a new field to 100 separate GUIs) will require manual labor? Also, am I right in thinking that the GUI designer is of little use in the context of heavily programmatic GUIs so something like a business rules engine would be written primarily in C#+XAML with little use of the GUI designer?

在一个客户的情况下，他们有几十个非常静态的类似 GUI（每年更改）和一些其他非常动态的 GUI（例如业务规则引擎）。他们已经拥有 F# 代码，并且已经在 F# 培训方面进行投资，因此技能可用性不是问题。我的印象是 C#+XAML 可以让您轻松构建静态 GUI（几个滑块、几个文本框等），但我看不出 GUI 设计器如何帮助程序化 GUI，如业务规则引擎。我是否认为维护一组大部分静态 GUI（例如，向 100 个单独的 GUI 添加一个新字段）需要手工劳动？还，

采纳答案by Stephen Swensen

I've done a good amount of GUI and non-GUI programming in C# and F#, in work and play, heavy programmatic and static... and I believe your stated impression is accurate and practical. (note that I am more familiar with WinForms than with WPF, but I don't think the differences matter here).

我已经在 C# 和 F# 中完成了大量 GUI 和非 GUI 编程，在工作和娱乐中，大量的编程和静态......我相信你陈述的印象是准确和实用的。（请注意，与 WPF 相比，我对 WinForms 更熟悉，但我认为这里的差异并不重要）。

My impression is that C#+XAML let you build static GUIs (a few sliders, a few text boxes etc.) easily but I cannot see how the GUI designer would help with programmatic GUIs like a business rules engine.

我的印象是 C#+XAML 可以让您轻松构建静态 GUI（几个滑块、几个文本框等），但我看不出 GUI 设计器如何帮助程序化 GUI，如业务规则引擎。

This is absolutely my experience. For mostly static GUIs, I prefer using the WinForms designer with C#. The tooling combo is great for these scenarios and is more productive than hand-coding the GUI with F# and no designer (now, if there were F# support with the designer, I would have no hesitation preferring that). I'm Only Restingis an example where I have preferred C# with the WinForms designer over pure F#.

这绝对是我的经验。对于大多数静态 GUI，我更喜欢在 C# 中使用 WinForms 设计器。工具组合非常适合这些场景，并且比使用 F# 和没有设计器的手动编码 GUI 更有效率（现在，如果设计器有 F# 支持，我会毫不犹豫地选择这样做）。I'm Only Resting是一个例子，我更喜欢 C# 和 WinForms 设计器，而不是纯 F#。

And for heavy programmatic GUIs, I believe it is best to avoid the designer altogether, rather than to attempt to go half designer half programmatic (it gets real messy, real quick). So in these cases I definitely prefer hand-coding the GUIs in F#, since everyone knows F# is the more expressive language ;) FsEyeis an example where I have preferred pure F# over C# with the WinForms designer.

对于繁重的程序化 GUI，我认为最好完全避免设计器，而不是尝试半设计器半程序化（它变得非常混乱，非常快）。因此，在这些情况下，我绝对更喜欢在 F# 中对 GUI 进行手动编码，因为每个人都知道 F# 是更具表现力的语言；) FsEye是一个示例，在该示例中，我更喜欢纯 F# 而不是使用 WinForms 设计器的 C#。

Am I right in thinking that maintaining a battery of mostly-static GUIs (e.g. adding a new field to 100 separate GUIs) will require manual labor?

我是否认为维护一组大部分静态 GUI（例如，向 100 个单独的 GUI 添加一个新字段）需要手工劳动？

Probably. I don't believe there is really any ready solution for this problem since it is really quite a large one. But there might be some best practices out there for building a custom solution right for your suite of software.

大概。我不相信这个问题真的有任何现成的解决方案，因为它确实是一个很大的问题。但是可能有一些最佳实践可以为您的软件套件构建自定义解决方案。

Also, am I right in thinking that the GUI designer is of little use in the context of heavily programmatic GUIs so something like a business rules engine would be written primarily in C#+XAML with little use of the GUI designer?

另外，我是否认为 GUI 设计器在大量编程的 GUI 上下文中几乎没有用处，所以像业务规则引擎这样的东西将主要用 C#+XAML 编写，几乎不使用 GUI 设计器？

Yes, like I said early, it is my belief that you ought not try to mix the GUI designer with heavy programmatic GUI programming.

是的，就像我早先说过的，我认为您不应该尝试将 GUI 设计器与繁重的程序化 GUI 编程混合在一起。

回答by Faisal Waris

I recently built a directed graph visualization application using purely F# and WPF.

我最近使用纯 F# 和 WPF 构建了一个有向图可视化应用程序。

For the 'programmatic' GUI parts, I essentially built WPF custom controls that I could operate with data binding and MVVM.

对于“程序化”GUI 部分，我基本上构建了可以使用数据绑定和 MVVM 操作的 WPF 自定义控件。

For the static parts I used XAML with out-of-the-box and custom WPF controls.

对于静态部分，我使用了带有开箱即用和自定义 WPF 控件的 XAML。

I used the FSharpX WPF Type Provider extensively for MVVM binding.

我广泛使用 FSharpX WPF Type Provider 进行 MVVM 绑定。

And this 'book' helped me quite a bit to get started. http://wpffsharp.codeplex.com/

这本“书”对我的入门帮助很大。http://wpffsharp.codeplex.com/

Some things don't come naturally with F# and WPF but in almost all cases a reasonably elegant solution was found. Some WPF data binding strings did become large and unwieldy.

F# 和 WPF 的某些事情并不自然，但在几乎所有情况下，都找到了一个相当优雅的解决方案。某些 WPF 数据绑定字符串确实变得又大又笨拙。

回答by Carsten

I don't know how exactly to answer the question as it's somewhat hard to get hold to so I just give you my 0.05$:

我不知道如何准确回答这个问题，因为这有点难以把握，所以我只给你我的 0.05 美元：

If you do WPF with a good MVVM (there are even Rx-Versions that are influenced by FP-land) you won't write code-behind (or almost none) - and with WPF type-providers and all the other great stuff that's around you can already write WPF-F# applications without any problem (even designer support is no problem - just use BLEND if you can - if not you can still seperate the GUI into a dumb C#-lib.)

如果您使用良好的 MVVM（甚至有受 FP-land 影响的 Rx 版本）执行 WPF，您将不会编写代码隐藏（或几乎没有）-以及使用 WPF 类型提供程序和所有其他很棒的东西您已经可以毫无问题地编写 WPF-F# 应用程序（即使设计器支持也没有问题-如果可以，只需使用 BLEND-如果不是，您仍然可以将 GUI 分离为一个愚蠢的 C#-lib。）

so why don't I write most GUIs in 100% F# then?

那么为什么我不用 100% F# 编写大多数 GUI 呢？

Well to be honest... it's the lack of refactoring and tools like ReSharper - it's just frustrating that I cannot search for F#-symbols or types because there is no freaking support in VS/R#er right now.

老实说......这是缺乏重构和像 ReSharper 这样的工具 - 令人沮丧的是我无法搜索 F# 符号或类型，因为现在 VS/R#er 中没有该死的支持。

It's strange but writting MVVM code where you have to create much trivial code for your Viewmodels seems to be easier to do in C# with the right tools right now (for example: I can configure R#er to insert me all the code for public probertys with private/public setters and INotifyPropertyChanged based on internal fields by just hitting - and choosing the right option - this will generate lot's of very dumb code but it's much faster that you could do in F#)

这很奇怪，但编写 MVVM 代码，您必须为您的 Viewmodel 创建许多琐碎的代码，现在似乎更容易使用正确的工具在 C# 中完成（例如：我可以配置 R#er 将所有代码插入公共探测器使用基于内部字段的私有/公共设置器和 INotifyPropertyChanged，只需点击 - 并选择正确的选项 - 这将生成大量非常愚蠢的代码，但它比你在 F# 中做得要快得多）

回答by ose

As you have pointed out, F# is a much scarcer skill among programmers in the general IT industry, whereas every man and his dog knows C# (or for that matter Java, C/C++ which easily translate across).

正如您所指出的，F# 在一般 IT 行业的程序员中是一种非常稀缺的技能，而每个人和他的狗都知道 C#（或者就这一点而言，Java、C/C++ 很容易翻译）。

Thus from a purely managerial point of view it likely makes more sense to go with C#+XAML over F# because of a number of factors:

因此，从纯粹的管理角度来看，由于许多因素，使用 C#+XAML 而不是 F# 可能更有意义：

1. Programmer's salaries - hiring an F# guru adds quite a bit to the salary budget
2. Development time - this could be argued either way see 1for a good comparison
3. Corporate risk - usage of F# greatly increases the risk factor in each of the categories:
   • Programmer leaves company and takes intellectual property with them
   • Programmer leaves company and company cannot hire a replacement => project misses deadline
   • Company does not have adequate metrics available to gauge the time required for the project
   • Language becomes depracated and code has to be ported (not as great a concern but still higher-risk than C#)
   • Etc. etc.

1. 程序员的薪水 - 聘请 F# 大师为薪水预算增加不少
2. 开发时间 - 无论哪种方式都可以对此进行争论，请参阅1以进行良好的比较
3. 企业风险 - F# 的使用大大增加了每个类别的风险因素：
   • 程序员离开公司并带走知识产权
   • 程序员离开公司，公司无法聘请替代者 => 项目错过了最后期限
   • 公司没有足够的指标来衡量项目所需的时间
   • 语言变得过时，必须移植代码（不是那么大的问题，但仍然比 C# 风险更高）
   • 等等等等。

However, from an engineering perspective, F# (perhaps with an add-on library for visualisations) is able to simply generate a powerful GUI. C#, though, also has this capability - you can generate your entire GUI without using XAML programmatically.

但是，从工程角度来看，F#（可能带有用于可视化的附加库）能够简单地生成强大的 GUI。但是，C# 也具有此功能 - 您可以在不以编程方式使用 XAML 的情况下生成整个 GUI。

As for adding a new item to 100+ GUIs, here I don't see how XAML is a disadvantage at all. If I understand your question correctly, you can use a Data Template which you can update once in XAML and have the change propagate across all your GUIs.

至于向 100 多个 GUI 添加新项目，在这里我完全看不出 XAML 有什么缺点。如果我正确理解您的问题，您可以使用数据模板，您可以在 XAML 中更新一次，并让更改在您的所有 GUI 中传播。

In conclusion I would suggest to you that unless you have a strong reason to use F#, stick with C# as it will reduce risk to your company in the long term.

总之，我建议您，除非您有充分的理由使用 F#，否则请坚持使用 C#，因为从长远来看，它会降低您公司的风险。

回答by Michael

I see alot of confusing answers and solutions here. F# and C# can be combined in solution. Let C# manage GUI and F# manage packages. Also, XAML vs WinForms is a no brainer. With XAML, There is more than enough room for code behind to do any and everything you need. If you're using WinForms then I do believe you need to retire from it immediately. WPF for example, is far more flexible and extremely powerful with GUI options far above those of WinForms. Not to mention the binding power of XAML. XAML is static but communicates with code behind just well and can communicate to any and all .NET languages. Use F#, use C# together and definitely leave the world of WinForms forever. Here is a little project that I've done. It uses only a combinatin of WPF, Silverlight, WCF, F#, C#, and VB.NET. WinForms wasn't touched and if you look closely you'll see that acheiving this with WinForms would have taken ages. I could have completed this with only one language but swapping helped save time depending on the situation but I only went forward, never backwards. WinForms as well as all other legacy options were ignored and never used.

我在这里看到很多令人困惑的答案和解决方案。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 不是 t 接触，如果你仔细观察，你会发现用 WinForms 实现这一点需要很长时间。我本可以只用一种语言完成这项工作，但交换有助于根据情况节省时间，但我只前进，从不倒退。WinForms 以及所有其他遗留选项都被忽略并且从未使用过。