C＃vs F＃用于程序化WPF GUI

Question

我正在尝试决定在企业软件开发中使用F＃和C＃的方法。 数学代码的F＃是不费吹灰之力的。 我喜欢F＃用于GUI工作，即使它缺乏GUI设计器支持，但当然，C＃GUI人员在工业中有更多的资源可用性。 但是，我不太熟悉C＃+ XAML GUI开发，所以我担心引入偏见。

在一个客户端的情况下，他们有许多类似的静态（每年更改）的GUI和一些非常动态的其他GUI（例如业务规则引擎）。 他们已经拥有F＃代码并且已经投资F＃培训，因此技能可用性不是问题。 我的印象是C＃+ XAML可以让你轻松地构建静态GUI（一些滑块，几个文本框等），但我看不出GUI设计师如何帮助像业务规则引擎这样的程序化GUI。 我是否正确地认为维持一组大多数静态GUI（例如向100个单独的GUI添加新字段）需要手工劳动？ 另外，我是否正确地认为GUI设计器在大量编程GUI的环境中没有什么用处，所以像业务规则引擎这样的东西主要用C＃+ XAML编写而几乎没有使用GUI设计器？

Answer 1

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

我的印象是C＃+ XAML可以让你轻松地构建静态GUI（一些滑块，几个文本框等），但我看不出GUI设计师如何帮助像业务规则引擎这样的程序化GUI。

这绝对是我的经历。 对于大多数静态GUI，我更喜欢使用带有C＃的WinForms设计器。 工具组合非常适合这些场景，并且比使用F＃手动编写GUI而没有设计人员更有效率（现在，如果设计师有F＃支持，我会毫不犹豫地选择这一点）。 我只是休息是一个例子，我更喜欢使用WinForms设计师的C＃而不是纯粹的F＃。

对于繁重的程序化GUI，我认为最好完全避开设计师，而不是尝试半设计师半程序化（它变得非常混乱，真正快速）。 所以在这些情况下我绝对更喜欢手工编写F＃中的GUI，因为每个人都知道F＃是更具表现力的语言;） FsEye是一个例子，我喜欢使用WinForms设计器的纯C＃over C＃。

我是否正确地认为维持一组大多数静态GUI（例如向100个单独的GUI添加新字段）需要手工劳动？

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

另外，我是否正确地认为GUI设计器在大量编程GUI的环境中没有什么用处，所以像业务规则引擎这样的东西主要用C＃+ XAML编写而几乎没有使用GUI设计器？

是的，正如我早期所说，我相信你不应该试图将GUI设计师与繁重的程序化GUI编程混合在一起。

Answer 2

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

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

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

我广泛使用FSharpX WPF类型提供程序进行MVVM绑定。

而这本“书”帮助我开始了很多。 http://wpffsharp.codeplex.com/

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

Answer 3

我不知道如何回答这个问题，因为有点难以接受，所以我只给你0.05美元：

如果你用一个好的MVVM做WPF（甚至有受FP-land影响的Rx版本），你将不会编写代码隐藏（或几乎没有） - 并且使用WPF类型提供程序和所有其他伟大的东西您可以在没有任何问题的情况下编写WPF-F＃应用程序（即使设计人员支持也没问题 - 如果可以的话，只需使用BLEND - 如果不是，您仍然可以将GUI分离为愚蠢的C＃-lib。）

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

说实话......这就是ReSharper缺乏重构和工具 - 我不能搜索F＃-symbols或类型，这是令人沮丧的，因为现在VS / R＃er没有任何支持。

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

Answer 4

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

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

1. 程序员的工资 - 雇用F＃guru会增加薪水预算
2. 开发时间-这可能是因为存在争论的方式看1用于比较好
3. 企业风险 - 使用F＃极大地增加了每个类别的风险因素：
   • 程序员离开公司并随身携带知识产权
   • 程序员离开公司和公司不能雇用替代=>项目错过最后期限
   • 公司没有足够的指标来衡量项目所需的时间
   • 语言变得匮乏，代码必须被移植（不是很重要，但仍然比C＃风险更高）
   • 等等

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

至于在100多个GUI中添加新项目，我在这里看不出XAML是如何处于劣势的。 如果我正确理解了您的问题，您可以使用数据模板，您可以在XAML中更新一次，并让更改在所有GUI中传播。

总之，我建议你，除非你有充分的理由使用F＃，坚持使用C＃，因为这样可以长期降低贵公司的风险。

Answer 5

我在这里看到了很多令人困惑的答案和解决方案。 F＃和C＃可以在解决方案中组合使用。 让C＃管理GUI和F＃管理包。 此外，XAML vs WinForms是一个没有脑子的人。 使用XAML，有足够的空间来代码执行任何操作和所需的一切。 如果您正在使用WinForms，那么我相信您需要立即退出。 例如，WPF的灵活性和功能非常强大，GUI选项远远高于WinForms。 更不用说XAML的绑定力了。 XAML是静态的，但很好地与代码进行通信，并且可以与任何和所有.NET语言进行通信。 使用F＃，一起使用C＃，绝对永远离开WinForms的世界。 这是我做过的一个小项目。 它仅使用WPF，Silverlight，WCF，F＃，C＃和VB.NET的组合。 WinForms没有被触及，如果仔细观察，你会发现使用WinForms实现这一目标需要花费很长时间。 我本可以用一种语言完成这项任务，但交换有助于节省时间，具体取决于具体情况，但我只是前进，从不倒退。 WinForms以及所有其他遗留选项都被忽略，从未使用过。