.net - 将 F# 用于 BLL 实现是否有意义？

Question

您认为使用 F# 来实现业务逻辑层是个好主意吗？我将使用 Entity Framework 作为“数据映射器”并使用 C# 实现 UI 逻辑。

欢迎任何想法。我将不胜感激任何帮助!

谢谢。

附言这样做的目的是什么？我是 F# 的新手，想尝试使用该语言(技术)。我必须实现一个相对较小的项目，获得 F# 经验可能会很好。

Answer 1

在 F# 中实现“实际数据处理”可能是目前 F# 最常见的用途，因此在 F# 中实现业务逻辑似乎是一个不错的选择。

我认为您无法直接从 F# 使用 Entity Framework (轻松)，因此您需要使用 C# 生成数据模型并将相关数据公开给 F#。如果您想使用 LINQ to SQL，那么您只需在 C# 中生成映射并使用 PowerPack 在 F# 中编写查询(如 Mitya 建议的那样)。

也许最简单的事情是拥有三个项目:

C# 中的数据访问层 ，它只使用 Entity Framework 并公开重要数据(使用 IEnumerable 类型，可以从 F# 轻松使用)。

F# 中的业务层 使用数据、执行“实际处理”并公开一些可从 C# 使用的类型。如果你声明了一个 class in F#，那么它会像任何普通的 .NET 类一样被编译，所以你可以很容易地从 C# 中使用它。您只需要注意不要在公共(public)接口(interface)中使用 F# 特定功能。一些建议是使用委托(delegate)(而不是函数)、类类型和 IEnumerable(在 F# 中称为 seq)而不是函数列表。

C# 中的用户界面 层，它调用在 F# 中声明的类型。如果您遵循上述简单规则，则 C# 代码可以轻松调用 F# 类型。

附带说明 - 尽管 F# 不支持设计器，但它对于用户界面编程非常有用(参见例如 this article 或我的演讲 about Silverlight in F# )。您可以做的一件事是在 C# 库项目中创建用户界面，将所有内容标记为公共(public)，然后从实际控制用户交互的 F# 项目中引用它。但是，这有点高级，所以我认为从业务层开始是一个好主意。