Question

我有兴趣将F＃在并行领域的优势应用到现有的.Net应用程序中。那就是 - 我想要考虑一个F＃组件，它只处理我的应用程序的并发消息，同时保留我现有的大部分.Net项目。现有应用程序将调用F＃组件。

1）这种架构是否可取？ 2）如果是这样，是否有任何例子证明了这种设计的最佳实践方法？

谢谢，

约翰

Answer 1

这当然是解决问题的有效方法。将应用程序的任何部分分解为单独的类库并没有什么不同。此过程的任何最佳实践都应适用于作为F＃的新DLL的语言。

以下无耻的自助促销：

如果您正在寻找采用此方法的真实世界示例，请查看一个项目是VsVim项目。它是Visual Studio的Vim模拟器，它依赖于F＃的核心功能，但使用C＃集成到Visual Studio中。

它可能不包含所有最佳实践，但它确实包含解决某些F＃构造的示例，这些构造在C＃或VB.Net等语言中使用可能很奇怪。特别是选择和受歧视的工会。

Answer 2

1）这种架构是否可取？

这当然不是一个糟糕的方法：）

我担心的主要问题是它如何影响团队的其他成员 - 他们是否需要学习一种新语言来添加新功能或调试问题？如果团队的其他成员不习惯使用它，您可能需要考虑在C＃中查找或构建自己的消息传递库。

2）如果是这样，有没有例子那里展示了最好的实践这种设计的方法？

我喜欢在我的项目中一直混合使用F＃和C＃。根据我自己的经验，利用F＃中的C＃dll比其他方式更容易。我们喜欢在F＃中使用的大多数构造在C＃中看起来很有趣且不直观。仅用于测试，请参阅以下代码在Reflector中的呈现方式：

let f x y z = x(y z)
let (|A|B|C|) x =
    match x with
    | 1 -> A
    | 2 -> B
    | x -> C x
type whatever = X | Y | Z of int

Curried函数呈现为FSharpFunc，活动模式有一个有趣的名称和返回类型，工会有一组非常奇怪的成员等等。它们在C＃中看起来很奇怪，所以你很可能想暴露具有更好的C＃签名的外观，适用于您希望公开使用的任何模块。例如：

module CSharpFacade =
    let f(x : System.Func<_, _>, y : System.Func<_, _>, z) = f (fun param -> x.Invoke(param)) (fun param -> y.Invoke(param)) z

    [<AbstractClass>]
    type Whatever() =
        inherit obj()
        abstract member Map : unit -> whatever
    type X() =
        inherit Whatever()
        override this.Map() = whatever.X
    type Y() =
        inherit Whatever()
        override this.Map() = whatever.Y
    type Z(value : int) =
        inherit Whatever()
        member this.Value = value
        override this.Map() = whatever.Z(value)

所以很容易将C＃的代表和联盟包装起来。我并不关心暴露活动模式，除非另有需要，否则它将是内部模式。

你可能希望将Some / None类型包装成更适合的东西，例如使用Nullable<someValueType>代替Option<someValueType>，并将null引用类型映射到None在需要的地方等等。

将F＃集成到现有的.Net应用程序中

2 个答案: