依賴注入模塊化依賴註冊

我試圖總是以模塊化的方式設計我的應用程序。我希望能夠在任何給定的交換模塊。依賴注入模塊化依賴註冊

使用依賴注入模式允許我這樣做。但是有些東西一直困擾我很多。

在大多數代碼我來跨越存在其中接口被鏈接到所期望的接口的單個地方。例如在asp.net vnext中，它看起來像這樣：

public void ConfigureServices(IServiceCollection services) 
{    
    // business-layer 
    services.AddTransient<IArticleRepository, ArticleRepository>(); 

    // data-layer 
    services.AddTransient<IDataConnection, DataConnection>(); 
}

但我不喜歡只有一個地方做註冊。我寧願每個模塊註冊自己的接口/實現：

在我的業務層（模塊）

public void ConfigureServices(IServiceCollection services) 
{    
    // business-layer 
    services.AddTransient<IArticleRepository, ArticleRepository>();   
}

在我的數據層（模塊）

public void ConfigureServices(IServiceCollection services) 
{    
    // data-layer 
    services.AddTransient<IDataConnection, DataConnection>();   
}

有任何圖案，或最好的做法來做這種事情？我可以創建一些接口並加載該接口的所有實現，但我不確定這是否是實現此目的的最佳方式。

來源

2015-11-07 mhtsbt

是否有任何圖案或最佳實踐做這樣的事情？

是，也不是。有Facade pattern，您可以爲客戶提供簡化的API，而無需對API進行精細控制。 Facade模式並不明確地關注依賴注入，但如果這是一件有意義的事情，你總是可以提供默認的服務組合。我的文章DI Friendly Library中有更多細節。

這就是說，保持API開放，使門面只是您提供給客戶的一個選項是非常重要的。如果您預先在庫中編寫了一個對象圖，並且不提供任何方法來規避該默認構圖，那麼這樣的庫就是一個單一的黑盒子。來自依賴注入的所有外部好處都將消失，因爲客戶端將無法替換或擴展服務。

請遵循DI Friendly Library文章中列出的指導原則，但一定要避免Conforming Container anti-pattern。

來源

2015-11-07 14:16:20

我要說的是，通道/地方配置您的DI的高度取決於你的DI框架。有些框架可以讓你執行每個模塊的配置，其他的需要一個全局配置。在後一種情況下，您可以手動委派您的子模塊（只需將IServiceCollection傳遞給子模塊配置代碼）。

有關最佳實踐：我很少看到DI的使用有多個生產實現。通常只有一種生產實施方式，而DI僅用於在沒有樣板的情況下將所有產品連接在一起。但許多不同的實現（通常是模擬）通常在沒有DI框架的情況下通過手動連線進行測試。如果這也是你的情況，那麼你的直覺就是對的：有一個DI框架可以掃描整個代碼，採用默認的/唯一的實現並將其注入爲依賴關係。如果你的DI框架提供了這個功能，那麼你很幸運。如果不是，你必須自己實施它

來源

2015-11-09 21:58:20 piotrek

依賴注入模塊化依賴註冊

回答

相關問題