2

我有一系列类，每个类根据它们的角色有几个依赖项。这些依赖项被注入到构造函数中。一个例子是：

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);

在设计模式/原则方面使用具有接口属性的交互接口是否有任何问题？或者有没有更好的方法来看待它？

感谢您的任何建议...

4

2 回答 2

3

一般来说，您不应该在内部创建具有不同服务的“上帝”服务。它打破了单一响应原则 (SRP)。

但是我不明白 DI 怎么会针对服务实例向您注入 null ？可能您应该针对创建“上帝”服务来解决此问题吗？

于 2012-12-29T05:33:49.637 回答
0

IMO，构造函数中的依赖注入是通向地狱的一种方式。您能否预测应用程序生命周期内的最终依赖项数量？你真的想每次都修改ctor的代码吗？您真的想一次初始化所有依赖项，而不是延迟初始化吗？

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

您绝对不应该测试空注入值。如果你的 DI 框架本身不能进行这些测试，那么就把它扔掉并使用普通的。

于 2012-12-29T05:43:56.063 回答