38

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

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

4

5 回答 5

21

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

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

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

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

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

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

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

是的，就像我之前所说的，我认为您不应该尝试将 GUI 设计器与繁重的程序化 GUI 编程混为一谈。

于 2012-11-23T22:50:52.250 回答
12

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

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

对于静态部分，我将 XAML 与开箱即用的自定义 WPF 控件一起使用。

我将 FSharpX WPF 类型提供程序广泛用于 MVVM 绑定。

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

F# 和 WPF 有些事情不是自然而然的，但几乎在所有情况下都找到了一个相当优雅的解决方案。一些 WPF 数据绑定字符串确实变得很大且难以处理。

于 2012-11-24T14:20:28.763 回答
9

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

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

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

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

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

于 2012-11-23T22:45:42.913 回答
5

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

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

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

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

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

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

于 2012-11-23T21:41:27.443 回答
1

我在这里看到很多令人困惑的答案和解决方案。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 以及所有其他遗留选项都被忽略并且从未使用过。

于 2014-07-29T06:03:23.543 回答