工廠模式在依賴注入

我有一個類，看起來像這樣：工廠模式在依賴注入

public class SomeRepo : ISomeRepo 
{ 
    private IThingFactory _thingFactory; 

    public class SomeRepo (IThingFactory thingFactory) 
    { 
     _thingFactory = thingFactory; 
    } 

    public IThing GetThingFromDatabase(int id) 
    { 

     string thingName = /* some call that gets back some primitives */ 
     IThing returnVal = _thingFactory.createThing(thingName); 

     return returnVal; 
    } 
}

因此，在短期，SomeRepo是一個回購協議，負責一些數據存儲通信得到一個IThing的標識。而IThingFactory是一個簡單的工廠，返回給定字符串屬性的new IThing。

如果我使用依賴注入容器，我還應該依靠IThingFactory嗎？爲了方便起見，我似乎混合了兩種設計模式。有沒有更好的方法來構建IThing而不需要工廠，或者我有一個好的模式可以遵循嗎？

謝謝

編輯：我使用的DI容器是Ninject。

來源

2016-05-13 Rhs

你能形容'IThing'嗎？有多少類實現它？這是一個簡單的財產包？它是否包含您可能想要改變的行爲？ –

'IThing'僅由1類實現，但可以通過在未來其他類來實現。這是一個單一的財產包。 – Rhs

看看[這篇文章newables和注射劑（http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/）。 –

如果我思的是，並不需要比輸出多從數據庫中的類（所以如果需要從DI容器沒有），你不想要嘲笑它進行測試，恕我直言，你可以通過調用創建類構造函數。

否則工廠模式是我眼中的正確選擇。

對於NInject，有一個factory extension，這使得創建工廠非常容易 - 您只需創建接口並在運行時創建相應的實現。

來源

2016-05-13 06:50:08 JanDotNet

依賴注入是實現層間鬆散耦合的技術，不完全是我將其描述爲設計模式的技術。

混合設計模式或使用多種技術作爲一般事情來說明沒有什麼錯，除非您在不需要的地方引入複雜性。

所以我的建議是通過質疑您的需求和理解設計模式的使用來處理事情，然後您將能夠認識到需要使用某種模式來使您的代碼可維護，可擴展或任何技術要求正在努力實現。

的問題，我都會問自己：

什麼是我試圖解決這個問題？

這個邏輯會如何擴展？什麼是移動部分，核心要求是什麼？

哪種設計模式解決了這種問題？

您還需要權衡引入代碼的複雜性和使用某些設計模式所耗費的時間以及在短期和長期使用它的好處？

來源

2016-05-13 06:20:52

工廠模式在依賴注入

回答

相關問題