c# - 是否应该将依赖项注入(inject)比需要的多很多 "levels"？

Question

我正在使用 SOLID 原则编写 C# ASP.NET MVC 网络应用程序。

我写了一个 ViewModelService，它依赖于一个 AccountService 和一个 RepositoryService，所以我在ViewModelServer。

PermissionService 依赖于 HttpContextBase 以便使用 GetOwinContext() 获取 UserManager。 Controller 有一个需要使用的 HttpContextBase 实例 - 所以看起来我必须将 HttpContextBase 实例注入(inject) ViewModelService 然后将其注入(inject) PermissionService。

所以，就我的代码而言:

public ViewModelService

public CategoryRepository(ApplicationDbContext context, IPermissionService permissionservice)

public AccountService(HttpContextBase httpcontext, IPrincipal securityprincipal)

为了实例化 ViewModelService，我然后这样做:

new ViewModelService(
    new CategoryRepository(
            new ApplicationDbContext(), 
            new PermissionService(
                new AccountService(HttpContext, Thread.CurrentPrincipal),
                new UserPasswordRepository(new ApplicationDbContext()),
                new ApplicationSettingsService())),
    new PasswordRepository(
            new ApplicationDbContext(), 
            new PermissionService(
                new AccountService(HttpContext, Thread.CurrentPrincipal), 
                new UserPasswordRepository(new ApplicationDbContext()),
                new ApplicationSettingsService())),
    new ModelValidatorService());

是否应该从这么多“级别”向上注入(inject)依赖项，还是有更好的方法？

Answer 1

需要取得平衡。

一方面，您的思想流派坚持认为所有依赖项都必须由类公开才能“正确”注入(inject)。 (这是一种将服务定位器之类的东西视为反模式的思想流派。)这样做有其优点，但如果走极端，您会发现自己处于现在的位置。某些本身具有复合模型的复合模型中恰到好处的复杂性会导致聚合根需要注入(inject) tons 依赖项来满足更深层次模型的依赖项。

我个人认为这会在这种情况下产生耦合。这是 DI 旨在解决的问题，而不是创建的问题。

另一方面，您的思想流派允许使用服务定位器方法，其中模型可以在内部调用一些公共(public)领域服务来解决它的依赖关系。这样做有其优点，但如果走到极端，您会发现您的依赖关系鲜为人知，如果无法解决任何给定的依赖关系，则可能会出现运行时错误。 (基本上，您可能会在更高级别遇到错误，因为使用对象永远不知道被使用的对象需要未提供的东西。)

就我个人而言，我经常使用服务定位器方法(主要是因为它是一种非常方便的模式，可以将 DI 引入遗留域作为更大的重构练习的一部分，这是我专业做的很多事情)并且从来没有遇到这样的问题。

有阴有阳。而且我认为每个解决方案空间都有自己的平衡点。如果您发现直接注入(inject)使系统难以维护，可能值得调查服务位置。相反，如果整个域模型本身是内在耦合的，并且这个 DI 问题只是该耦合的一个症状而不是它的原因，这可能也值得研究。