我主要开发业务线应用程序.没有科学操作.没有复杂的计算.只需将用户界面与数据库绑定即可.我使用线程的唯一原因是在后台做一些工作，并且仍然保持UI响应.
这可能不是最好的方法，但这就是我所遵循的
1.首先创建一个工作应用程序(没有线程)，并将其交给最终用户进行播放，以获得反馈
步骤1&；2完全不同，线程代码主导实际代码.
1.如果是业务线应用程序，F#会让我的生活更轻松吗？
2.有没有什么特别的UI技术最适合F#？我主要从事ASP.NET&；Silverlight的工作.现在使用WPF(&A；T).
3.有没有使用F#的业务线应用程序/演示的好例子？
我不是问是否可以用F#开发业务线应用程序.我想问的是，与C#相比，F#是否会让我的工作更容易开发业务线应用程序？我主要关注的是线程化和用户界面同步.
我和你在同一条船上，做着许许多多的业务类型的应用程序，没有什么像游戏、编译器或搜索引擎那样"有趣".
你的里程数will各不相同，但至少在我自己的经验中，很多开发团队都不愿意直接跳入F#，因为团队中没有其他人知道或听说过它.一开始，你就必须面对这样的问题:"它与C#有什么不同？"如果你能说服你的老板让你用它写几个演示应用，那就试试吧！
话虽如此，我发现C#不太擅长业务规则，但它像冠军一样处理GUI；F#的不变性使GUI开发变得笨拙，但业务规则和工作流感觉很自然.因此，这两种语言各有长处，互补性强.
在我自己的LOB应用程序中，F#在几个方面围绕C#运行:
F#的异步工作流和邮箱处理器比本机线程甚至任务并行库更易于使用.自从使用邮箱处理器进行线程间通信以来，我甚至不记得上一次必须锁定或线程的时间.join()任何东西都可以进行同步.
使用联合FTW定义业务规则引擎和DSL！我开发过的每一个非平凡的LOB应用程序都有自己的半成品规则语言和解释器，它几乎总是基于递归地打开枚举来钻取规则并找到匹配项.我目前的项目包含1300多个公共类，大约900个是表示规则的简单容器类.我认为将规则表示为F#union将大大减少代码inflating ，并有助于实现更好的引擎.
不可变代码只工作better次——如果你得到一个状态无效的新对象，你不需要搜索太远就能找到有问题的代码行，你需要知道的一切都在调用堆栈上.如果你有一个状态无效的可变对象，有时你需要花很多时间来追踪它.你可以用C#编写不可变的代码，但很难不依赖于可变性，尤其是当你在循环中修改一个对象时.
I hate个空值.我不能给出准确的估计，但是感觉我们在生产中得到的错误有一半是空引用异常--一个对象被错误地初始化，您只有在代码中有30个堆栈帧时才会知道这一点.我认为F#会帮助我们第一次编写更多无bug的代码.
C#通常在以下情况下运行良好:
您正在编写GUI代码或使用内在可变的系统.
向许多不同的客户机公开DLL或web服务.
你的老板不会让你使用你想要的工具；)
因此，如果你能克服"我们为什么要使用新的语言障碍"，我认为F#确实会让你的生活更轻松.