2016-01-21 85 views
0

我是TPL-Dataflow的自我培訓,我已經讀過使用消息的不可變對象是要走的路。消息類型與DataFlow塊

爲了符合這一點,我爲每個塊輸入和輸出設計了特定的類。

不幸的是,當我將阻擋對方,因爲塊輸入和輸出類型有很大的不同,它導致鏈接到的TransformBlock激增:

var proc1 = new TransformBlock<proc1In,proc1Out>(... 
var convertOut1toIn2 = new TransformBlock<proc1Out,proc2In>(p1 => new proc2In { ... 
var proc2 = TransformBlock<proc2In,proc2Out>(... 

proc1.LinkTo(convertOut1ToIn2); 
convertOut1ToIn2.LinkTo(proc2); 

使用批處理和加入塊後合併結果一起讓我與一個非常混亂的代碼糾纏在一起。

我在互聯網上閱讀的每個樣本都使用簡單的類型,如int,string ......我還沒有找到任何處理更復雜類型的內容。

我覺得使用單個大對象並將其引用通過所有塊的衝動。在做這個錯誤之前,我想知道是否有更好的方法去做。

回答

0

經過一段時間TPL-Dataflow沉思,事實證明:

  • 構想數據流作爲輸送帶的承載對不同工位製造項目,其中項目被充實和建立是完全錯誤:這樣做方式會導致難以解決的併發問題。數據流是一個消息傳遞系統。

  • 相反,我覺得它更好的描繪它作爲一個網的人誰與外部設施把事情交易(IO,數據庫持久性,CalculationEngines ...)

問題我使用Tuples輕鬆規避了我處理的消息類型。一般來說,我不喜歡Tuples醜陋,但在這種情況下,我覺得他們真的適合這個地方。

我的問題是多圖分析。而不是讓塊互相傳遞一個「工作項目」對象並混淆它,我寧願使用一個單獨的「WorkItemSupplier」類。該類使用WorkItems的ConcurrentDictionary並公開方法來處理工作項。

這樣,我在Dataflow中的塊只能傳遞工作項的ID,因此他們可以使用WorkItemSupplier作爲外部工具來存儲/檢索或更改任何工作項的狀態。

通過這種方式,代碼運行的方式更加平滑,分離和易於閱讀。

+0

此外[此問題](http://stackoverflow.com/questions/26560374/dataflow-with-splitting-work-to-small-jobs-and-then-group-again#comment41783122_26580148)幫助了很多過濾/從多個結果合併塊。 – Larry

相關問題