我正在尝试决定在企业软件开发中使用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设计器吗？
答案 0 :(得分：21)
我已经在C＃和F＃中完成了大量的GUI和非GUI编程，在工作和娱乐，繁重的程序设计和静态......我相信你的陈述印象是准确和实用的。 （请注意，我对WinForms比对WPF更熟悉，但我不认为这些差异很重要。）
我的印象是C＃+ XAML允许您构建静态GUI（少数 滑块，几个文本框等）很容易，但我看不出如何GUI 设计师可以帮助像程序化的GUI，如业务规则 发动机。
这绝对是我的经验。对于大多数静态GUI，我更喜欢使用带有C＃的WinForms设计器。工具组合非常适合这些场景，并且比使用F＃手动编写GUI而没有设计人员更有效率（现在，如果设计师有F＃支持，我会毫不犹豫地选择这一点）。 I'm Only Resting是一个例子，我更喜欢使用WinForms设计师的C＃而非纯F＃。
对于繁重的程序化GUI，我认为最好完全避开设计师，而不是尝试半设计师半程序化（它变得非常混乱，真正快速）。所以在这些情况下我绝对更喜欢手工编写F＃中的GUI，因为每个人都知道F＃是更具表现力的语言;）FsEye是一个例子，我更喜欢使用WinForms设计器的纯C＃over C＃。
我是否正确地认为保持电池主要是静电的 GUI（例如，向100个单独的GUI添加新字段）将需要 体力劳动？
可能。我不相信这个问题确实有任何现成的解决方案，因为它真的是一个很大的问题。但是可能有一些最佳实践可以为您的软件套件构建自定义解决方案。
另外，我认为GUI设计器没什么用处 大量程序化GUI的上下文，就像一个企业 规则引擎主要用C＃+ XAML编写，几乎没有使用 GUI设计师？
是的，正如我早些时候所说，我相信你不应该试图将GUI设计师与繁重的程序化GUI编程混合在一起。
答案 1 :(得分：12)
我最近使用纯粹的F＃和WPF构建了一个有向图可视化应用程序。
对于'程序化'GUI部分，我基本上构建了WPF自定义控件，我可以使用数据绑定和MVVM进行操作。
对于静态部分，我使用XAML开箱即用和自定义WPF控件。
我广泛使用FSharpX WPF类型提供程序进行MVVM绑定。
这本'书'对我起步很有帮助。 http://wpffsharp.codeplex.com/
有些事情并不是F＃和WPF自然而然的，但在几乎所有情况下都找到了一个相当优雅的解决方案。一些WPF数据绑定字符串确实变得庞大且难以处理。
答案 2 :(得分：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代码，你必须为你的Viewmodel创建很多简单的代码，现在使用正确的工具在C＃中更容易做（例如：我可以配置R＃er来插入我的所有代码对于具有私人/公共设置者的公共probertys和基于内部字段的INotifyPropertyChanged只需点击 - 并选择正确的选项 - 这将产生很多非常愚蠢的代码，但是你可以在F＃中做得更快。）
答案 3 :(得分：5)
正如您所指出的那样，F＃在一般IT行业的程序员中是一种非常稀缺的技能，而每个人和他的狗都知道C＃（或者就此而言，Java，C / C ++很容易翻译）。
因此，从纯粹的管理角度来看，由于许多因素，使用C＃+ XAML而不是F＃更有意义：
然而，从工程角度来看，F＃（可能带有可视化的附加库）能够简单地生成功能强大的GUI。但是，C＃也具有此功能 - 您可以在不以编程方式使用XAML的情况下生成整个GUI。
至于向100多个GUI添加新项目，在这里我看不出XAML是如何处于劣势的。如果我正确理解了您的问题，您可以使用数据模板，您可以在XAML中更新一次，并让更改在所有GUI中传播。
总之，我建议您除非您有充分的理由使用F＃，否则请坚持使用C＃，因为这样可以长期降低贵公司的风险。
答案 4 :(得分：0)
我在这里看到了很多令人困惑的答案和解决方案。 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以及所有其他遗留选项都被忽略，从未使用过。