IoC容器是否取代了工厂的使用
我刚刚开始使用IoC容器，如果这是一个愚蠢的问题，请道歉。
我在应用程序中有如下代码
internal static class StaticDataHandlerFactory { public static IStaticDataHandler CreateHandler(StaticDataUpdate staticDataUpdate) { if (staticDataUpdate.Item is StaticDataUpdateOffice) { return new OfficeUpdateHandler(); } if (staticDataUpdate.Item is StaticDataUpdateEmployee) { return new EmployeeUpdateHandler(); } if (staticDataUpdate.Item == null) { throw new NotImplementedException( string.Format("No static data provided")); } else { throw new NotImplementedException( string.Format("Unimplemented static data type of {0}", staticDataUpdate.Item.GetType().FullName)); } } } 它基本上是一个简单的工厂，它返回处理输入数据的正确策略。
IoC容器是否允许我删除这样的代码？ 也就是说：它是否允许我根据输入参数的类型动态选择要加载的具体实现？
还是我离开这里？
实际上，尽管可以用控制系统的反转来替换一些代码，但对我来说这并不是一个好主意。 dependency injection往往最适合系统配置，而不是动态创建对象。 换句话说，容器本身是一个巨大的全局变量，因此应该出现在你的大部分代码中。
另外，代码似乎违反了得墨忒耳法则 。 看来参数应该是“StaticDataUpdateItem”类型而不是“StaticDataUpdate”。 通过观察，有一个非常强大的论据，可以将此代码重写为StaticDataUpdateItem上的方法调用。
我非常重视IoC，但使用抽象工厂模式仍然可以更好地处理动态对象。 简而言之，如果您不喜欢向项目本身添加方法以生成句柄的想法，那么代码可能最好保持原样。
你离现场不远了; 我理解它的方式，你非常接近。
我最常构建这种方法的方法是将Factory类转换为IoC容器，只需允许使用dependency injection指定返回的UpdateHandler即可。 因此，代码中没有指定StaticDataUpdateOffice意味着返回OfficeUpdateHandler的代码，您可以将代码简单地说为StaticDataUpdateOffice返回任何（新指定的） m_officeUpdateHandler变量包含的内容; 只要您的Framework确保在调用工厂之前设置m_officeUpdateHandler的值，就可以了。 并且您可以根据需要更改将m_officeUpdateHandler的值更改为运行时所需的任何值。
此dependency injection允许您控制反转控制过程; 您可以拥有一个返回处理程序的简单工厂，并且可以根据需要抽象控制将处理程序返回到其他位置的逻辑。
注意：我对这种事情的体验很大程度上取决于我对Spring的非常积极的体验，所以这可能会使我对你的问题（和答案）的解释变得更加明确。
简短的回答是肯定的，它允许它。 这篇博文显示了使用Windsor在运行时选择实现的灵活方式。 作者Ayende 在这里和这里详细阐述。
我还没试过，但我希望很快。
我同意这里的其他答案，是的，你可以这样做。 但是，你为什么不使用通用？
public static IStaticDataHandler CreateHandler( params object[] args ) {...
args可以作为ctor参数传递给（例如，Activator）。
我还没有读到任何有用的话。
IoC更适合配置？
动态对象创建更好么？ generics？ 这完全是主题。
1）与实现’专业化/inheritance’福音书相比，IoC只是一个节省时间的好时机。
所以使用IoC的规则＃1你应该真的厌倦了必须处理跟随’绑定到合同而不是实现’的长构造函数。
换句话说，这是作为模板模式的替代方案的策略模式，出于同样的原因（封装……）……但是创建所有额外的接口/抽象类型是更多的工作，这是更多的工作要做它每次都与IServiceProvicerThis和IResolverThat …如果您不厌倦不得不繁琐地履行代码合同，例如：
IInterestingService有趣= …但是你得到了一个实例..
添加大约三个像这样的行..
然后
IAmazementService服务=新的AmazementService（有趣的，这些策略，第三等…）
那变老了。 所以IoC永远不是一个问题，因为任何聪明到使用可靠设计进行编码的人都会更清楚。 那些要求的人都有错误的答案。
所以，如果你确实满足上述那么绝对。 IoC容器可以做很多“创造”的工作，因为你可以从让它们处理中受益。 对于明确的新事物，最常见的创造性抽象是工厂先生。
达蒙