IoC,你把集装箱放在哪里?

这使得代码更加复杂,更难测试、维护、重用和读取。

如果您的组件确实需要在内部实现动态解析(即,基于名称来解析异常处理策略或工作流),那么我建议考虑 lending IoC powers via the highly-specific providers

我建议你看看尼克·布卢姆哈特关于这个的迷你系列。

http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx

示例:God对象有一个getFoo()方法和一个getBar()方法。对象A需要一个Foo,对象B需要一个Bar。如果A只需要一个Foo,那么Foo应该直接注射到A中,而A根本不应该意识到上帝。但如果A需要继续创造食物,那么提到上帝几乎是不可避免的。但你们可以通过缩小提及上帝的范围来保护自己不受上帝的伤害。如果您让God实现FooFactory并引用God实现的FooFactory,那么您仍然可以以上下文无关的方式编写代码。这提高了代码重用的机会,并增强了您对上帝的改变不会导致意外副作用的信心。例如,当您从God中删除getBar()时,可以确定类A不会中断。

虽然我欣赏“专门构建的工厂”的明确性,甚至我自己也在使用它们,但在我自己的设计中,这感觉像是一种代码味道,因为公共接口(小“I”)随着每个实现的新工厂和/或新的GetX方法而不断变化。读了杰里米·米勒的 It's time for IoC Container Detente ,我怀疑泛型和注入容器本身才是正确的选择。

IServiceLocator container = ContainerFactory.GetContainer(); 
while( keepLooping )
{
    IExample example = container.GetInstance<IExample>();
    keepLooping = example.DoWork();
}

您的容器工厂始终可以返回相同的intance,您可以交换IoC框架,等等。

在这种情况下,我建议使用您提到的强类型工厂,这些工厂将被注入。这些工厂可以包装容器,但可以允许在其他上下文中传递,并进行额外的处理。例如,OrderFactory上的Create可以接受上下文参数。

在通用服务定位器上具有静态依赖性是一个坏主意,因为您失去了意图和上下文。当IoC构建实例时,它可以基于一系列因素(如proifle、context等)提供正确的依赖关系,因为它具有全局性。

CommonServiceLocator并非用于此目的,尽管您可能会尝试使用它。CommonServiceLocator的主要用途是用于希望跨IoC容器兼容的应用程序/框架。然而,使用定位器的应用程序最好只调用一次定位器,以建立组件及其依赖项的层次结构。它不应该再被直接调用。如果我们有办法强制执行,我们会的。棱镜( http://www.microsoft.com/compositewpf )我们引入了用于构建模块的IContainerFacade。这是一个低级别的服务定位器。回想起来,我们可能应该创建一个ModuleFactory或其他东西,并使用IContianerFacade来获取它,然后使用它来解析模块,而不是直接进入门面。事后诸葛亮。这是足够低的水平,虽然它并不真正影响事情。

在CSL上,我们努力解决命名问题,因为它可能会导致混淆。最后,我们决定使用CSL,因为从技术上讲,接口不适合您进行DI。

作为后续行动 @flipdoubt

如果您最终使用服务定位器类型模式,您可能希望签出 http://www.codeplex.com/CommonServiceLocator

祝你好运

Typed Factory Facility