c# - Controller 注入(inject)服务类依赖关系还是留给服务来解决它自己的依赖关系？什么是首选方式

Question

我有以下类，后者服务类耦合到特定容器，但如果我使用前者，为什么 Controller 类应该注入(inject)服务类依赖项而不是仅使用服务类并将其留给服务类来解决依赖项？

public class ProfileController {

    public ProfileController(IProfileService profileService, IProfileRepository  profileRepository, IUnitOfWork unitOfWork, IDatabaseFactory databaseFactory) {
    profileService.Get();
    }
}

public class ProfileService:IProfileService {

    public ProfileService(IProfileRepository  profileRepository, IUnitOfWork unitOfWork, IDatabaseFactory databaseFactory) {
    profileService.Get();
    }  
}

或

public class ProfileController {
    public ProfileController(IProfileService profileService) {
                            profileService.Get();
    }
}

public class ProfileService:IProfileService {

    public ProfileService() { 
        var dbfactory=container.Resolve<IDatabaseFactory>();
        var unitofwork=container.Resolve<IUnitofWork>();
        var rep=container.Resolve<IProfileRepository>();
        rep.Get();
    }  
}

Answer 1

服务类不应该解析它的依赖关系。所以你应该选择选项 1。实例应该完全不知道 DI 容器。

为什么？

关注点分离:依赖注入(inject)的重要思想是将对象的实例化视为一个独特的关注点，在一个地方处理:容器。创建实例并在它们之间设置引用是容器的工作。当您让实例本身使用容器时，您就破坏了这个概念。

模块类的可重用性:当你有一个“使用”DI 容器的类时，你不能再在不同的体系结构中使用这个类，包括不同的 DI 框架，而不改变它。尽管您可能不想这样做，但您会无缘无故地限制自己。

语义清晰:您的构造函数参数应回答以下问题:创建该类的实例需要什么。在您的情况下，这是一些东西:IDatabaseFactory 等，而不是什么都没有 (())。

可测试性:您不希望您的类需要整个 DI 基础结构才能工作。也许出于测试原因，模型应该做的是，在运行时由您的 DI 容器完成。这与“可重用性”有关。

快速失败:假设依赖关系不可解析:在构建容器时抛出异常，而不是在实例化类时抛出异常，这很好。

总结:

container.Resolve(...)

不应出现在您的模块中。