具有静态和动态依赖关系的 IoC

Question

我正在尝试在我的应用中实现 IoC。我有这个模型：

interface IService;
interface IComponent;

class Service : IService
    Service()

class Component : IComponent
    Component(IService service, object runtimeValue) { }

在我的应用程序中的某个时间点，我需要获得IComponent。我的应用程序使用 IoC 容器 (Unity)。我可以在容器中注册Service，但我不能为它的依赖关系runtimeValue 的Component b/c 做同样的事情。根据this，我必须使用工厂并在我需要的任何地方注入IComponent：

interface IComponentFactory
     IComponent CreateComponent(object runtimeValue)

class ComponentProvider : IComponentProvider
     ComponentProvider(IComponentFactory factory) { }

     IComponent CreateAndCacheComponent(object runtimeValue) {
         _component = factory.CreateComponent(runtimeValue)
         return _component
     }

     // other methods

我必须能够向容器注册工厂，因此它必须只有静态依赖项。同时它必须能够提供创建组件所需的IService 类型的服务实例。
这是工厂实现。我唯一能想到的就是使用Func<> 委托作为依赖：

class ComponentFactory : IComponentFactory
    ComponentFactory(Func<IService> serviceFactoryDelegate)

    IComponent CreateComponent(object runtimeValue) {
        return new Component(serviceFactoryDelegate.Invoke(), runtimeValue)
    }

...并将代理注册到容器中作为静态工厂，以便它回调容器来解析服务（我在 .net 2.0 上使用 Unity 1.2）：

Container
    .Configure<IStaticFactoryConfiguration>()
    .RegisterFactory<Func<IService>>(container => (Func<IService>)container.Resolve<IService>)

现在我可以使用容器来解析 ComponentProvider 并根据运行时值获取组件：

// this happens inside CompositionRoot
provider = Container.Resovle<IComponentProvider>()
component = provider.CreateAndCacheComponent("the component")

现在我对此有一些疑问：

1. 工厂打电话给new Component(...) 我很不高兴。这不是穷人的DI吗？

2. 在工厂的构造函数上使用Func<IService> 时好莱坞原则是否仍然有效？我的意思是，它最终调用 container.Resolve... 有点像 SL。唯一的区别是代码在应用的容器注册部分，而不是在工厂类中。

3. 就 DI 和 IoC 而言，此实现是否有任何（其他）问题？

Answer 1

1. 不，不是。工厂的全部目的是创建具体类的实例。
2. 基本上，是的，但正如我在评论中已经问过的，我不明白为什么这是必要的。您可以直接注入IService 的实例

3. 它比它需要的要复杂一些。为什么双重重定向IComponentProvider -> IComponentFactory？看起来IComponentFactory 并没有带来任何好处。

   像这样实现ComponentProvider：

   class ComponentProvider : IComponentProvider
   {
       ComponentProvider(IService service) { _service = service; }
   
       IComponent CreateAndCacheComponent(object runtimeValue) {
           _component = new Component(_service, runtimeValue);
           return _component;
   }
   

   这将为您带来以下好处：

   1. 您摆脱了不必要的接口IComponentFactory 以及相应的实现。
   2. IService无需注册工厂

---

一般来说，你如何实现它取决于你真正需要什么：

"runtimeValue" 在整个运行时可以是相同的，例如从设置中读取的连接字符串。在这种情况下，不需要工厂/提供者，您可以简单地新建实例并将其注册到容器中。每个需要IComponent 的人都在构造函数而不是提供程序中请求一个。

如果“runtimeValue”在对 CreateAndCacheComponent 的调用之间确实发生变化，您将只实现一个工厂并将其作为依赖项传递。

Answer 2

1. 与Poor Man's DI 相比，这是一个很大的进步，但如果您不必在每次将新的依赖项添加到组件的构造函数时都更改此工厂方法，那就太好了。
2. 这本身不是问题。把它想象成你在注入一个匿名工厂类。它仍然可以被模拟以进行单元测试，并且可以更改绑定，因此您仍然可以获得 DI 的好处。但它是一个额外的抽象层，可能不是必需的。在这种情况下，您仍然可以通过将IService 直接注入工厂而不是Func 来避免它。
3. 通常在使用依赖注入时，您希望注入 services 而不是 values。您发现必须同时拥有两者的事实可能表明您需要重新考虑您的类的 API。例如，也许您应该将值传递给类的方法，而不是构造函数。如果不了解更多细节，很难说最好的方法是什么。

Answer 3

对于问题1：在工厂里打电话new没有错。您已将实例化隔离到应用程序中的一个位置；你只是把那个地方放在工厂而不是容器上。

如果您需要模拟或更改实现，您只需模拟或更改工厂实现，而不是单独的组件。