我是新來依賴注入並有一個問題/需要指導。ModelMap DI上的StructureMap DI
我有一個使用存儲庫模式進行數據訪問的應用程序。我使用StructureMap來獲取正確的存儲庫，並且一切正常。
我已經將我的模型（包括存儲庫邏輯）分解爲它自己的程序集並添加了一個服務層。爲了DI的利益，服務層類在其構造函數中接受一個IRepository。這對我來說似乎是錯誤的，因爲現在我的模型的所有消費者都需要知道存儲庫（至少配置它們的DI以知道使用哪一個）。我覺得這是進入模型的膽量。
這聽起來有什麼問題嗎？
寫入使用依賴注入一個應用程序通常配置在所有的接口/實現類型映射已在應用程序的初始化階段中被註冊的單個容器實例。這將包括註冊存儲庫，服務以及該應用程序中的所有服務使用者。
通過通過容器解決服務的消費者，消費者只需要在服務說明的依賴，沒有任何依賴該服務可能需要。因此，該服務的使用者將不會與其依賴關係（例如您的存儲庫）耦合。這是通過容器進行依賴注入的好處，而不是手動依賴注入。
如果你正在設計服務，其他應用程序中可重用庫的形式被消耗掉，然後你的選擇將取決於靈活性要提供的水平而有所不同。
如果你假定你的庫的所有客戶端將使用依賴注入，則需要提供相關文件，適量什麼類型需要被他們的容器內註冊。
如果假定所有客戶端將使用的特定容器（例如StructureMap），則可以緩解通過提供封裝所有客戶端的特定註冊需求的註冊的註冊要求。
如果你希望允許不使用自己的依賴注入容器的客戶端使用您的圖書館，你可以提供一個靜態工廠返回的服務。根據複雜程度的不同，這種情況可能不需要使用容器（例如，如果您的服務僅由幾個對象組成）。如果您的庫由大量需要組成的組件組成，那麼您可能會有工廠通過他們自己共享的內部基礎架構初始化需求來解決這些服務。
我明白你的困境，丹，我也花了很多時間在腦海裏摔跤。我相信我決定推進的方式是封裝所有問題並仍然具有易於維護的鬆散耦合對象的最佳方法之一。
我專門寫這個博客帖子大約NHiberante，但如果你看看存儲庫模式中實現，你可以很容易地改變NH特定的代碼來使用你的備份存儲。
Creating a common generic and extensible NHiberate Repository