依赖注入 – 为什么不通过你的IoC容器？

发布时间：2020-12-14 04:31:06 所属栏目：百科来源：网络整理

导读：在这个AutoFac“最佳实践”页面( http://code.google.com/p/autofac/wiki/BestPractices)上，他们说：不要通过集装箱将组件访问容器，或将其存储在公共静态属性中，或者在全局“IoC”类上使Resolve()等功能可用，从而达不到使用依赖注入的目的。这样的设计

在这个AutoFac“最佳实践”页面( http://code.google.com/p/autofac/wiki/BestPractices)上，他们说：

不要通过集装箱
将组件访问容器，或将其存储在公共静态属性中，或者在全局“IoC”类上使Resolve()等功能可用，从而达不到使用依赖注入的目的。这样的设计与服务定位器模式更相似。
如果组件对容器有依赖关系，请查看它们如何使用容器检索服务，并将这些服务添加到组件的(依赖注入)构造函数参数中。

那么，一个组件“动态地”实例化另一个组件的更好方法是什么呢？他们的第二段不包括“可能”需要创建的组件将取决于系统的状态的情况。或者当组件A需要创建X个组件B时。

要抽出另一个组件的实例化，可以使用Factory模式：

public interface IComponentBFactory
{
    IComponentB CreateComponentB();
}

public class ComponentA : IComponentA
{
    private IComponentBFactory _componentBFactory;

    public ComponentA(IComponentBFactory componentBFactory)
    {
        _componentBFactory = componentBFactory;
    }

    public void Foo()
    {
        var componentB = _componentBFactory.CreateComponentB();

        ...
    }
}

然后实现可以向IoC容器注册。

容器是组合对象图的一种方式，但它并不是唯一的方法。这是一个实现细节。保持没有这种知识的对象将它们从基础设施问题中解脱出来。它也使得他们不必知道要解决哪个版本的依赖关系。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!