在TPL數據流網絡中流動的項目應該是DTO還是POCO？

Question

（現在，我用首字母縮寫詞引起了您的注意...）

提出這個問題的更好方法可能是： 什么時候應該使用DTO，什么時候應該在TPL Dataflow網絡中使用POCO ？ （因為更好的選擇可能取決於情況）。

我已經做到了這兩種方式，而且我不確定何時使用其中一種。 處理邏輯是應該放在塊中（即傳遞給標准塊的lambda）還是應該像往常一樣封裝在對象中？

（提醒一下，在此POCO與DTO問題中討論了什么DTO和POCO 。）

我傾向於在網絡中流動的DTO約占70％，因為：

• 在設計/編碼數據流網絡時，我的思維模型專注於多階段轉換管道-數據先轉換后再轉換。 重點是轉換，而不是每種數據項的“行為”。 我想看到這些轉換是一堆我可以一起瀏覽的（相對）小的函數（lambda）。

• 流中的項目通常不是應用程序模型類的實例，它們通常只是在流中創建並在流結束時銷毀的實例。 （有時候，他們的壽命只能長到可以從一個街區傳到另一個街區。）

另一方面：

• 有時您可能會認為數據項正在經歷連續的轉換，這將對數據類的封裝行為產生影響。

• 如果您確實將行為封裝在數據類中，那么創建數據流塊並將其連接起來就成為樣板（因為在塊的lambda中沒有完成特定於數據的工作），因此您可以創建相當通用的構建器，以輕松地描述構建任何網絡。

（我相對確定的唯一一件事是，不應將樣式混合在一個網絡中。）

但是我沒有足夠多變的經驗，無法制定任何准則來建議如何選擇。 我正在尋找這樣的指導方針，或要考慮的贊成/反對論點。

Answer 1

這取決於您執行的處理類型，我認為TDF對此決定沒有任何影響。

如果您執行的操作確實是該項目的“方法”（例如Eat是Hamster Eat ），那么請對該項目本身具有邏輯。 另一方面，如果項目與過程之間沒有真正的聯系（例如，例如記錄），並且項目只是“通過”一個塊，那么就具有該塊方法的邏輯。

Answer 2

Petri Net令牌的基類應該是什么？

UML活動圖中對象節點的基類應該是什么？

任何課程都可以

盡管您的問題很冗長，但對我而言，它屬於同一問題/答案類別