什麼樣的設計模式適合LOAD-CONVERT-WRITE類似的場景？

我不想重新發明車輪。什麼樣的設計模式適合LOAD-CONVERT-WRITE類似的場景？

是否有適合下面工作流程的設計模式或模式。想法是有一個通用的解決方案，將適合所有：LOAD DATA - >將其轉換 - >寫入已轉換的

像：

（1）LOAD DATA：從數據源加載數據和產生一個IEnumerable

（2）COVNERT加載的數據 - 通過加載的數據漫遊，並且將它們在一個轉換邏輯轉換成TConverted類型

（3）WRITE轉換後的數據 - 遍歷IEnumerable和每個項目寫入到一個txt文件

來源

2012-10-16 pencilCake

相信Pipelines pattern MSDN上的好C# .NET 4.0 implementation。

想法是提取階段，併爲每個階段調度TPL的新實例Task，然後通過BlockingCollection<T>實例將所有實例綁定爲中間緩存。

另外值得注意的是，在引用的MSDN論文中提到的BlockingCollection.GetConsumingEnumerable()返回IEnumerable<T>如你所願。

一般流程例如：

enter image description here

來源

2012-10-16 12:19:05 sll

我不明白爲什麼我需要一個並行任務？你可以解釋嗎？對我來說，這聽起來像一個操作按順序... – pencilCake

你說，返回的數據是'IEnumerable'，所以你可以加快整個過程，如果你會讀出部分，並推動轉換，所以當你讀下一個數據部分前一個已經在轉換階段，所以這個woudl加速巨大的數據集處理，因此將成爲不同數據源的通用解決方案 – sll

有道理......實際上，當我從SQL Db中讀取這些大數據時，它會算什麼？與LINQ查詢？（或者只有當我用SqlDataReader讀取時纔會計數？） – pencilCake

我相信你正在尋找Adapter模式。我經常把這種轉化看作是一種既不傾向於客戶也不傾向適應者的中介階層。包裝的想法並不總是「感覺」非常抽象。但是，編寫專門用於使輸入數據適應客戶期望的類的類也可能是最好的。如果您認爲這違反了您的抽象，請考慮創建基類或接口並針對傳入數據的具體情況實施這些類。

來源

2012-10-16 13:26:06

「模板方法」模式可以幫助您構建一個通用框架，該框架可用於爲不同類型的數據實施此過程。會有一個抽象基類是這樣的：

public abstract class ETLProcess { 
    public final runETL() { 
     IEnumerable rawData = extract(); 
     IEnumerable tranformedData = transform(rawData); 
     load(transformedData); 
    } 

    protected abstract IEnumerable extract(); 
    protected abstract IEnumerable transform(IEnumerable rawData); 
    protected abstract load(IEnumerable transformedData); 
}

然後你就可以通過擴展ETLProcess類實現不同類型的數據的過程。這種模式的優點是你可以在抽象類中定義你的過程，並且在具體類中定義單獨的步驟。你可以把普通的代碼，常見的錯誤處理等放在基類中。

來源

2012-10-16 14:39:33 Sameer

什麼樣的設計模式適合LOAD-CONVERT-WRITE類似的場景？

回答

相關問題