IOC最佳实践:如何最佳管理依赖关系图?

您的依赖关系图看起来不错。如图所示,每个类只有 一 附属国

• 应用程序控制器依赖于控制器
• 控制器依赖于身份验证服务
• AuthenticationService依赖于UserRepository

我认识到这是一个简化的视图,您的实际生产体系结构将更加复杂,但是DI的优点(以及 构造器注入 尤其是)它违反了 Single Responsibility Principle 如此明显。

当一个类开始有太多的依赖关系时,这是你应该 refactor to an Aggregate Service .

最终的依赖关系图可能是 巨大的 但是每个类只依赖于一些抽象,所以从体系结构的角度来看,这不是问题。

您不应该解析图中间的实例。解决问题是你 do in the Composition Root 而且(理论上)只有一次。

当涉及到单元测试时, shouldn't have to use a DI Container at all .

不确定ApplicationController与控制器的关系,但一般来说,您的控制器将依赖于您的服务,而您的服务将依赖于存储库。

例如

public MyXyzController
{
  public MyXyzController(IAuthenticationService authenticationService){...}
}

public class AuthenticationService : IAuthenticationService
{
  public AuthenticationService(IUserRepository userRepository){...}
}

这样,当您请求(即解析)控制器时,IOC容器将自动解析所有依赖项。