1

我正在爲我的程序使用IoC容器unity。在依賴工廠之間傳遞數據對象

我有多個鏈接工廠。一個調用下一​​個來創建一個它需要填充屬性的對象。所有的工廠都使用相同的原始數據對象來構建它們各自的對象。原始數據對象描述瞭如何創建所有各種對象。目前,每個工廠都有一個Create方法,它接受一對參數來指定對象所代表的位置。

我的問題是如何將原始數據對象傳遞給每個工廠以便他們完成工作?

將對象注入到Create()方法中似乎比面向對象更程序化。但是,如果我將對象注入每個工廠的構造函數,那麼我將如何正確解析每個工廠。更不用說這些工廠需要能夠處理不同的原始數據對象。也許有更好的建築?

下面表示我有的結構類型,減去任何地方的原始對象。

class PhysicalObjectFactory 
{ 
    private readonly StructureAFactory _structureAFactory; 
    private readonly Parser _parser; 

    public PhysicalObjectFactory(StructureAFactory structureAFactory, Parser _parser) 
    { 
     _structureAFactory = structureAFactory; 
     this._parser = _parser; 
    } 

    public PhysicalObject CreatePhysicalObject() 
    { 
     RawDataObject rawDataObject = _parser.GetFromFile("foo.txt"); 
     // do stuff 
     PhysicalObject physicalObject = new PhysicalObject(); 
     physicalObject.StructureA = _structureAFactory.Create(num1, num2); 
     // do more stuff 
     return physicalObject; 
    } 
} 

class StructureAFactory 
{ 
    private readonly StructureBFactory _structureBFactory; 

    public StructureAFactory(StructureBFactory structureBFactory) 
    { 
     _structureBFactory = structureBFactory; 
    } 

    public StructureA Create(int a, int b) 
    { 
     // do stuff 
     StructureA structureA = new StructureA(); 
     structureA.StructureB = _structureBFactory.Create(num76, num33); 
     // do more stuff 
     return structureA; 
    } 
} 

class StructureBFactory 
{ 
    public StructureBFactory(){} 

    public StructureB Create(int a, int b) 
    { 
     StructureB structureB = new StructureB(); 
     // do stuff 
     return structureB; 
    } 
} 

回答

1

我的問題是如何/我在哪裏原始數據對象傳遞給每個 工廠,以便他們做好本職工作?

一般來說,您應該通過構造函數注入通過方法和編譯時/設計時/配置數據傳遞運行時數據。

您的服務與其使用時間不同。這些服務可以存活很長時間,這意味着它們可以多次使用不同的運行時值。如果您在運行時間數據和在整個服務生命週期內不會更改的數據之間做出區分,那麼您的選項會變得更加清晰。

所以問題是你傳遞的原始數據在每次調用時是否改變,或者是否是固定的。也許它是部分修復的。在這種情況下,你應該分開數據;只通過Create方法傳遞運行時數據。看起來顯而易見的是,由於工廠是鏈接的,他們需要創建該部分對象的數據通過它們的Create方法傳遞給它們。

然而,有時候,你有一些介於兩者之間的數據。它是在應用程序生命週期中將會更改的數據,但不希望通過方法調用將其傳遞,因爲調用者無法確定這些值是什麼。這是上下文信息。這方面的一個明顯例子是關於正在執行請求的登錄用戶的信息。您不希望調用者(例如您的表示層)傳遞該信息,因爲這是額外的工作,並且如果表示層忘記傳遞此信息或意外傳遞一些無效值,則可能存在安全風險。

在這種情況下,最常見的解決方案是注入一項服務,爲消費者提供此信息。在用戶信息的情況下,您將注入IUserContext服務,該服務包含UserNameUserId屬性,或許是IsInRole(string)方法或類似的東西。這裏的技巧是,用戶信息不是注入到消費者中,而是允許訪問這些信息的服務。換句話說,用戶信息的檢索是推遲的。這允許組合的對象圖保持獨立於這些上下文信息。這使得更容易編寫和驗證對象圖。

+0

這使現在更有意義。我沒有考慮到我的原始數據對象在設計時與運行時間方面的差異。我相信你最後一段的解決方案就是我需要的。我需要類似於中介模式的東西。提供原始數據對象的服務。我會做的。謝謝! – devinh64