c# - 具有静态和动态依赖性的IoC

我正在尝试在我的应用程序中实现IoC。我有这个模型：interface IService;interface IComponent;class Service : IService Service()class Component : IComponent Component(IService service, object runtimeValue) { }在我的应用程序中的某个时刻，我需要获取一个IComponent。我的应用程序使用IoC容器（Unity）。我可以在容器中注册Service，但不能对其依赖项Component的runtimeValue 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 CompositionRootprovider = Container.Resovle<IComponentProvider>()component = provider.CreateAndCacheComponent("the component")现在我对此有一些疑问：我不满意工厂致电new Component(...)。这不是穷人的DI吗？在工厂的构造函数上使用Func<IService>时，好莱坞原则是否仍然成立？我的意思是，它最终调用了container.Resolve ...有点像SL。唯一的区别是代码在应用程序的容器注册部分中，而不是在工厂类中。就DI和IoC而言，此实现是否还有其他问题？ (adsbygoogle = window.adsbygoogle || []).push({}); 最佳答案 与穷人的DI相比，这是一大步，但是如果您不必在每次将新的依赖项添加到Component的构造函数时都更改此工厂方法，那将是很好的选择。这本身不是问题。就像在注入一个匿名工厂类一样。仍然可以对它进行模拟以进行单元测试，并且可以更改绑定，因此您仍然可以获得DI的好处。但这是一个附加的抽象层，可能没有必要。在这种情况下，仍然可以通过直接将IService而不是Func注入工厂来避免这种情况。通常，在使用依赖项注入时，您希望注入服务而不是值。您发现必须同时拥有两者的事实可能表明您需要重新考虑类的API。例如，也许您应该将值传递给类而不是构造函数上的方法。如果不了解更多细节，很难说出最佳方法是什么。 (adsbygoogle = window.adsbygoogle || []).push({});