2010-06-09 110 views
3

我有兴趣将F#在并行领域的优势用于现有的.Net应用程序。也就是说,我想考虑一个F#组件,该组件仅处理我的应用程序的并发消息,同时保留现有的大多数.Net项目。现有的应用程序会调用F#组件。将F#集成到现有的.Net应用程序中

1)这个架构是否明智? 2)如果是这样,那么是否有任何示例说明了此设计的最佳实践方法?

感谢,

约翰

回答

4

1)这个架构是可取的吗?

这当然是个不错的办法:)

我很担心的是如何影响团队的其他成员最主要的 - 将他们需要学习一种新的语言添加新功能或调试问题?如果你的团队中的其他人不习惯使用它,你可能需要考虑在C#中寻找或构建自己的消息传递库。

2)如果是这样,是否有任何的例子出来 那里,表现出最佳 实践方法,以这样的设计?

我喜欢在我的项目中随时混用F#和C#。根据我自己的经验,利用F#中的C#dll比其他方式更容易。我们喜欢在F#中使用的大多数构造在C#中看起来很有趣,并且不直观。只是为了funsies,请看下面的代码在反射器中的呈现方式:

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 

咖喱功能呈现为FSharpFunc,活动模式有一个有趣的名字和返回类型,工会有一个很奇怪的一组成员,等他们看奇怪的是,所以你很可能希望公开一个更好的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) 

因此,它非常简单地包装F#代表和C#的工会。我并不真正在意暴露主动模式,除非另有需要,否则它将成为内部模式。

,你可能想要包装的东西有些/无类型更可口,如代替Option<someValueType>使用Nullable<someValueType>,并映射null引用类型None在需要的地方,等

+2

一般情况下,避免所有F#当您想从其他语言使用F#程序集时,在装配边界处使用特定的构造。 – Brian 2010-06-09 19:12:16

4

这无疑是解决问题的有效方法。这与将应用程序的任何部分分解为单独的类库完全没有区别。任何有关此过程的最佳做法应适用于作为F#的新DLL的语言。

无耻的自我推广下图:

如果你要寻找的是采取这种方法有一个项目来看待现实世界的例子是VsVim项目。它是Visual Studio的Vim模拟器,它依赖于F#的核心功能,但使用C#集成到Visual Studio中。

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

相关问题