耦合到依赖注入框架

Question

前言

在使用DI框架时,我觉得有可能用脚射击自己.
(我选择的框架是ninject,所以我将在我的例子中使用它.)

我将退后一步,看看DI 框架存在的原因:
为了防止必须手工完成DI

是的,根据Ninjects文档的精神,我们可以说我们Dojo创建了Samurai一个.这些Samurai是IWeapon在制作时给出的.

class Samurai{
    readonly IWeapon weapon;

    public Samurai(IWeapon weapon){
        this.weapon = weapon;
    }
}

现在,它是我的理解,Dojo将使用Kernel.Get<IWeapon>()时,它会创建一个Samurai.

Woah
我不是只把我的Dojo连接到内核吗？
另外......如何获得内核:DI,单身,服务地点？

我觉得我们很快就打败了DI的目的,因为现在我依赖于我的DI框架.如果忍者被击败并且ninject也会死亡会怎么样？

如何在不耦合DI框架的情况下使用DI？

我确定之前已经问过这个问题,但我找不到任何东西.请使用评论发布相关问题,以便我们汇集知识以找出最佳解决方案.

Answer 1

在执行依赖注入时,技巧是让所有类通过构造函数注入其依赖项.这样您就可以让内核从根对象中为您构建完整的对象图.

然而,这个"根对象"必须通过调用直接解决kernel.Get<HomeController>()(如果HomeController是根对象).所以在你的应用程序的某个地方,你将不得不打电话kernel.Get.没有它是不可能的.

诀窍是将此最小化到理想情况下应用程序中的单行代码并将其放置在启动路径附近.可能靠近您注册依赖项的地方.应用程序的其余部分无视任何DI框架的使用.

甚至还有Ninject和其他容器的集成包,允许您根据您使用的应用程序平台删除该单行代码.例如,ASP.NET MVC具有很好的可扩展性点,允许您插入一个ControllerFactory允许您让工厂kernel.Get为您调用的扩展点.

如何在不耦合DI框架的情况下使用DI？

总会有一些耦合,但理想情况下这应该只是启动路径.所有其他代码都应该忽略容器的使用.仍然存在程序集依赖关系,但此依赖关系仅存在于启动项目中,而不存在于业务层中.

看看DI框架存在的原因:防止必须手工完成DI

更确切地说.DI有助于使您的应用程序更易于维护.DI框架有助于使应用程序的启动路径(也称为组合根)更易于维护.