注入具有接口屬性和設計原則的接口

我有一系列的類，每個類都有一些依賴於它們的角色的依賴關係。這些依賴項被注入到構造函數中。一個例子是：注入具有接口屬性和設計原則的接口

public class UserViewModel 
{ 
    //... 
    public UserViewModel(IDataService dataService, 
         INotificationService notificationService, 
         IDialogService dialogService, 
         INavigationService navigationService) 
    { 
     this.DataService = dataService; 
     this.NotificationService = notificationService; 
     this.DialogService = dialogService; 
     this.NavigationService = navigationService; 
    } 
}

正如你所看到的，有幾個參數來設置。我可以寫如下所示的界面：

public interface IInteractionService 
{ 
    public INotificationService NotificationService { get; set; } 
    public IDialogService DialogService { get; set; } 
    public INavigationService { get; set; } 
}

，並通過注入InteractionService落實到UserViewModel的構造在一塊：

public UserViewModel(IDataService dataService, 
     IInteractionService interactionService) {}

，並用它喜歡：

this.InteractionService.NotificationService.Publish(message);

是在設計模式/原則方面使用保持接口屬性的交互接口有什麼問題？還是有更好的方法來看待它？

感謝您的任何意見...

來源

2012-12-29 Alyce

一般情況下，你不應該創建一個內部的不同服務的「上帝」的服務。它打破了單一響應原則（SRP）。

但我不明白，怎麼能是DI注入您對服務的一個實例空？可能是你應該修復這種行爲反對創建「上帝」服務？

來源

2012-12-29 05:33:49

沒有意識到檢查空值是不必要的，謝謝你。所以你認爲應該保留它的第一個片段 - 分別注入每項服務？ – Alyce

是的。如果這三項服務是獨立的，不要將它們結合在一起。 –

IMO，在構造函數依賴注入是通向地獄之路。你能預測應用程序生命週期中最終的依賴關係數量嗎？你真的想每次修改ctor的代碼嗎？你真的想要一次初始化所有的依賴，而不是懶惰的初始化嗎？

MEF，例如，可以在注入惰性方式私有字段。

你絕對不應該測試空注入值。如果你的DI框架本身不做這些測試，那就把它扔掉並使用正常的測試。

來源

2012-12-29 05:43:56 Dennis

私人領域注入更難以測試，並且不如構造函數注入那樣可讀。 –

注入具有接口屬性和設計原則的接口

回答

相關問題