Nib*_*Pig 0 c# inversion-of-control unity-container
我现在正试图绕过IoC,我就是那里的一部分.我在SO的另一篇文章中找到的一个例子是:
http://blog.vascooliveira.com/unity-tutorial-and-examples/
我不太了解的是:
ILogger myExampleInstance = myContainer.Resolve(loggerType);
Run Code Online (Sandbox Code Playgroud)
我不确定loggerType是什么,因为它没有在任何地方提到它.
我可以看到,在这种情况下,IoC允许我们创建一种编写日志的方法.我们不是在代码中实例化特定类型的记录器,而是使用IoC来创建ILogger接口,然后我们对其进行编码.这意味着我假设我们并不特别关心使用什么类型的Logger.如果我们不在乎,我很想知道为什么我们需要传递一个loggerType,或者我们如何知道loggerType是由于关注点的分离.
我是理解它的一半,但我只需要最后的推动!=)
你看到的实际上是一种称为服务定位器的反模式.示例代码直接引用容器,调用其Resolve()方法.
在99%的情况下,您不应该在代码中引用容器 - 在代码的最高级别应该只有一个应用程序范围的容器引用.(最后1%的案例几乎完全是您正在使用的框架不允许依赖注入的情况)
在对容器的单个引用中,根据需要新建对象,并将所有依赖项注入有效状态.所有对象都接收它们的依赖项作为参数(通常传递给构造函数).
有很多博客文章(这里有两个我发现的一些快速谷歌搜索:你不应该参考IoC容器和服务定位器是一个反模式解释为什么ServiceLocator是坏的各种原因.
您已经找到一个关于loggerType应该是什么的问题的示例,使用适当的IoC,您的应用程序应该不关心 - 服务定位器方法往往意味着您的应用程序开始再次意识到其依赖关系的细节,这与整个点相反首先使用IoC和dependecy注入.
为了进一步阅读IoC,我建议浏览StructureMap创建者Jeremy Miller的博客文章.不要因为我说使用StructureMap而不是Unity,但是因为他从头开始写了一个容器,他对这个主题所说的大部分内容都经过深思熟虑,他是一个好作家.