依赖注入 – 如何使用依赖注入而不是服务定位器

我听到有人说你不应该使用Service Locator进行依赖注入.那么,如何在不依赖服务定位器的情况下注入依赖项?我想尝试IoC容器,但不想陷入反模式.

你应该只设置一切所以有一个地方所有类总是有最深层的依赖链? (如果我/它完全有意义)

我对你的所有代码都依赖于所选择的IoC容器是不对的,是吗?

那么你在哪里“使用”你的容器(用于重新解析)?你如何解决所有问题,就像你的代码一样深入?它是通过每层直到前层使用接口来正确设计所有内容的一部分吗?

或者我只是错过了一点?

让我提醒你,我只是不想陷入反模式,需要一些提示/提醒它.

Should you just set everything up so
there is one place where all classes
always have a dependency chain to the
deepest classes? (if I/that makes
sense at all)

是的,这称为应用程序的组合根,您可以在此配置IoC容器并解析根类型.

It isn’t right to have all your code
littered with dependencies on the IoC
container of choice,is it?

正确的是,最好不要在类型周围传递对IoC容器的引用,因为这会使它们不再可重用,并且通常将类型与IoC容器的概念结合起来.

So where do you “use” your the
container (for rexolving)? And how do
you get it to resolve everything,as
deep as your code goes? Is it a part
of designing everything the right way
by using interfaces through every
layer up till the front layer?

您可以在组合根目录中使用容器,并在代码中的任何位置使用容器(通常用于依赖链支持)来实例化类型(即来自工厂类型).

许多IoC容器可以为您生成这些工厂类型,因此您只需要通过,例如IMyFactory作为依赖项,或者在某些IoC容器的情况下,是一个Func< IMyService>.这意味着您不需要创建依赖于IoC容器的工厂类型.

在使用接口方面,依赖性倒置原则声明您应该依赖于抽象,而不是依赖于具体结果,因此如果您希望采用依赖注入,则需要考虑此概念.

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...