c# - 业务应用程序 : Will F# make my life easy?

Question

我主要开发业务线应用程序。没有科学操作。没有复杂的计算。只需将用户界面绑定(bind)到数据库。我使用线程的唯一原因是在后台做一些工作并仍然保持 UI 响应。

这可能不是最好的方法，但这是我遵循的方法

1.首先创建一个工作应用程序(无线程)并将其提供给最终用户以进行反馈。
2.一旦所有需求都被锁定，我会尝试在任何对提高性能有意义的地方使用线程。

步骤 1 和 2 的代码截然不同，线程代码主导了实际代码。

1.对于业务线应用程序，F# 会让我的生活更轻松吗？
2.是否有任何特定的 UI 技术最适合 F#？我主要从事 ASP.NET 和 Silverlight 方面的工作。时不时地使用 WPF。
3.是否有使用 F# 的业务线应用程序/演示的好的示例？

我不是在问是否可以用 F# 开发业务线应用程序。我想问的是，与 C# 相比，F# 是否能让我更轻松地开发业务线应用程序？我主要关心的是线程和 UI 同步。

Answer 1

我和你在同一条船上，开发了很多很多业务线类型的应用程序，没有什么比游戏、编译器或搜索引擎更“有趣”的了。

你的里程数会不同，但至少根据我自己的经验，很多开发团队都不愿意直接进入 F#，因为团队中没有其他人知道甚至没有听说过它。马上，您必须解决诸如“它与 C# 有何不同之处？”之类的问题。如果你能说服你的老板让你用它编写一些演示应用程序，那就去做吧!

因此，话虽如此，我发现 C# 在业务规则方面不是很擅长，但它处理 GUI 的能力非常出色； F# 的不变性使 GUI 开发变得笨拙，但业务规则和工作流感觉很自然。所以两种语言各有长处，取长补短。

在我自己的 LOB 应用程序中，F# 在几个方面绕着 C# 运行:

• F# 的异步工作流和邮箱处理器比 native 线程甚至任务并行库更易于使用 数量级。自从使用邮箱处理器进行线程间通信以来，我什至不记得上次我不得不锁定或 thread.join() 任何东西以进行同步是什么时候了。

• 使用联合 FTW 定义业务规则引擎和 DSL!我曾经开发过的每一个重要的 LOB 应用程序都有自己的半生不熟的规则语言和解释器，而且它几乎总是基于递归地切换枚举来钻取规则并找到匹配项。我目前的项目现在包含 1300 多个公共(public)类，其中 900 个左右是表示规则的简单容器类。我认为将规则表示为 F# 联合会显着减少代码膨胀并打造更好的引擎。

• 不可变代码的工作更好 -- 如果您得到一个状态无效的新对象，您不必搜索很远就能找到有问题的代码行，您需要的一切要知道在调用堆栈上。如果您有一个状态无效的可变对象，有时您必须花费大量时间来追踪它。您可以在 C# 中编写不可变代码，但很难不依赖可变性，尤其是当您在循环中修改对象时。

• 我讨厌 null。我无法给出确切的估计，但感觉我们在生产中遇到的错误中有一半是空引用异常——一个对象未​​正确初始化，直到代码深入到 30 个堆栈帧时你才知道它。我认为 F# 会帮助我们在第一时间编写出更多没有错误的代码。

C# 通常在以下情况下运行良好:

• 您正在编写 GUI 代码或使用本质上可变的系统。

• 向许多不同的客户端公开 DLL 或 Web 服务。

• 你的老板不会让你使用你想要的工具 ;)

因此，如果您能克服“我们为什么要使用一种新语言的障碍”，我认为 F# 确实会让您的生活更轻松。