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

Question

我正在尝试决定在企业软件开发中使用F#和C#的界限在哪里。数学代码的F#是不费吹灰之力的。我喜欢用于图形用户界面工作的F#，尽管它缺乏图形用户界面设计器的支持，但是，当然，在行业中C#图形用户界面人员有更多的资源可用。但是，我不太熟悉C#+XAML图形用户界面的开发，所以我担心引入偏差。

在一个客户端的情况下，他们有几十个类似的GUI，它们是非常静态的(每年都会改变)，而其他一些GUI是非常动态的(例如，业务规则引擎)。他们已经有了F#代码，并且已经投资于F#培训，所以技能可用性不是问题。我的印象是C#+XAML允许您构建静态GUI(几个滑块、几个文本框等)。很容易，但我看不出GUI设计器如何像业务规则引擎一样帮助编程GUI。我认为维护一组基本静态的GUI(例如，向100个单独的GUI添加新字段)将需要手工劳动，这是正确的吗？另外，我认为图形用户界面设计器在高度程序化的图形用户界面环境中用处不大，因此业务规则引擎之类的东西将主要用C#+XAML编写，而很少使用图形用户界面设计器，这样的想法正确吗？

Answer 1

在工作和娱乐中，我在C#和F#中做了大量的图形用户界面和非图形用户界面编程，繁重的编程和静态...我相信你所说的印象是准确和实际的。(请注意，我对WinForms比对WPF更熟悉，但我认为这里的区别并不重要)。

我的印象是C#+XAML可以让你构建静态GUI(几个滑块，几个文本框等等)很容易，但我看不出GUI设计器如何像业务规则引擎一样帮助编程GUI。

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

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

我认为维护一组基本静态的GUI(例如，在100个单独的GUI中添加一个新字段)将需要手工劳动，这是正确的吗？

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

还有，我是否认为图形用户界面设计器在高度程序化的GUI环境中用处不大，所以业务规则引擎之类的东西将主要用C#+XAML编写，而很少使用图形用户界面设计器？

是的，就像我之前说过的，我相信你不应该把GUI设计器和繁重的编程GUI编程混为一谈。

Answer 2

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

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

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

我广泛地使用了MVVM类型提供者来进行FSharpX绑定。

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

有些事情并不是F#和WPF天生就有的，但在几乎所有的情况下，我们都找到了一个相当优雅的解决方案。一些WPF数据绑定字符串确实变得很大且笨重。

Answer 3

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

如果你用一个好的MVVM做WPF (甚至有受FP-land影响的Rx版本)，你就不会写代码隐藏(或者几乎没有)--有了WPF类型提供程序和周围所有其他优秀的东西，你已经可以毫无问题地写出WPF-F#应用程序(即使是设计器支持也没有问题--如果可以就使用BLEND --如果不能，你仍然可以将GUI分离到一个愚蠢的C#库中)。

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

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

这很奇怪，但是使用正确的工具在C#中编写MVVM代码似乎更容易(例如:我可以配置R#er使用私有/公共setter插入公共probertys的所有代码，并基于内部字段插入INotifyPropertyChanged，只需点击-并选择正确的选项-这将生成许多非常愚蠢的代码，但它比在F#中快得多)