我有興趣將F#在並行領域的優勢用於現有的.Net應用程序。也就是說,我想考慮一個F#組件,該組件僅處理我的應用程序的併發消息,同時保留現有的大多數.Net項目。現有的應用程序會調用F#組件。將F#集成到現有的.Net應用程序中
1)這個架構是否明智? 2)如果是這樣,那麼是否有任何示例說明了此設計的最佳實踐方法?
感謝,
約翰
我有興趣將F#在並行領域的優勢用於現有的.Net應用程序。也就是說,我想考慮一個F#組件,該組件僅處理我的應用程序的併發消息,同時保留現有的大多數.Net項目。現有的應用程序會調用F#組件。將F#集成到現有的.Net應用程序中
1)這個架構是否明智? 2)如果是這樣,那麼是否有任何示例說明了此設計的最佳實踐方法?
感謝,
約翰
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
在需要的地方,等
這無疑是解決問題的有效方法。這與將應用程序的任何部分分解爲單獨的類庫完全沒有區別。任何有關此過程的最佳做法應適用於作爲F#的新DLL的語言。
無恥的自我推廣下圖:
如果你要尋找的是採取這種方法有一個項目來看待現實世界的例子是VsVim項目。它是Visual Studio的Vim模擬器,它依賴於F#的核心功能,但使用C#集成到Visual Studio中。
它可能不包含所有的最佳實踐,但它確實包含了解決某些F#構造的例子,這些構造在C#或VB.Net等語言中可能很奇怪。特別是選擇和歧視工會。
一般情況下,避免所有F#當您想從其他語言使用F#程序集時,在裝配邊界處使用特定的構造。 – Brian 2010-06-09 19:12:16