c# - Ioc 中繁忙的构造函数——它们是代码的味道吗？

Question

我最终得到了一个看起来像这样的构造函数，同时试图得到一个我可以轻松测试的对象。

 public UserProvider(
            IFactory<IContainer> containerFactory,
            IRepositoryFactory<IUserRepository> userRepositoryFactory,
            IFactory<IRoleProvider> roleProviderFactory,
            IFactory<IAuthenticationProvider> authenticationProviderFactory,
            IFactory<IEmailAdapter> emailAdapterFactory,
            IFactory<IGuidAdapter> guidAdapterFactory,
            IRepositoryFactory<IVehicleRepository> vehicleRepositoryFactory,
            IRepositoryFactory<IUserVehicleRepository> userVehicleRepositoryFactory,
            IFactory<IDateTimeAdapter> dateTimeAdapterFactory)

这是对象将具有的所有依赖项，并且是我拥有的最繁忙的构造函数。但是，如果有人看到这个，它真的会引发巨大的 wtf 吗？

我的目标是最终得到易于测试的逻辑。虽然它需要大量模拟，但验证我的逻辑当然非常容易。但是我担心我可能会得到太多好东西。

我很好奇这对大多数实现 ioc 的人来说是否正常。

我可以做一些简化——比如我真的不需要为几个适配器传递工厂，因为我可以直接传递适配器，因为它没有内部状态。但我真的是在问参数的数量。

或者更确切地说，我正在寻求保证我不会过火 ;)

但我开始觉得应该对 UserProvider 类进行一些分解 - 但后来我得到了更多的管道，这就是引发这种担忧的原因。

我想一个子问题是，如果我有这些顾虑，我是否应该考虑使用服务定位器模式？

Answer 1

当使用 DI 和构造函数注入(inject)时，对 SRP 的违反变得非常明显。这实际上是一件好事，不是 DI/IOC 的错。如果您不使用构造函数注入(inject)，该类将具有相同的依赖关系，只是不那么可见。

您在具体示例中可以做的是将一些相关的依赖项隐藏在外观后面。例如，IVehicleRepository 和 IUserVehicleRepository 可以隐藏在 IVehicle facade 后面。将 IUserRepository、IRoleProvider 和 IAuthenticationProvider 放在外观后面也可能有意义。