我整个上午一直在研究如何找到访问IoC的最佳做法。在将构造函数注入添加到类之后，您仍然需要从可能位于应用程序对象图深处的类中访问contianer。在我的情况下，我在WPF中做MVVM，我的一些View Models需要创建其他View Models，他们会使用容器来做到这一点。但问题是他们从何处获取容器。注入并传递它是否有意义？是否可以使其成为可注射的单身人士？供应单身人士的工厂是否更适合？
选项和权衡是什么？
更新
我发现Matt Hinze的这篇精彩演讲涵盖了很多IoC基础：http://www.drowningintechnicaldebt.com/ShawnWeisfeld/archive/2010/04/08/inversion-of-control-in-action-by-matt-hinze-north.aspx
看起来一个答案是使用扫描功能并将IoC配置存储在每个程序集的注册表中，然后在扫描期间将添加这些注册表配置。
还有其他方法需要考虑吗？特别是考虑到Matt演示了使用ServiceLocator模式，而Mark Seeman称之为反模式。请注意，Matt警告不要过度使用该模式，并且Mark对服务定位器的定义（http://blog.ploeh.dk/Trackback.aspx?guid=5f05c086-295b-41e5-a50a-ed0cd77ac4bd）似乎与Matt演示的不同
答案 0 :(得分：2)
如您所说，您可以将工厂注入到顶级ViewModel，而不是注入实际的ViewModel实例，这很难。它有点像服务定位器模式，期望工厂（或服务提供商，或者你有什么）在他们能够提供的内容中更加具体。
答案 1 :(得分：0)
其中一种方法是使用指向特定容器的ServiceLocator。由于定位器通常以单例形式公开，因此您可以从代码中的任何位置免费获取容器。
例如，在Unity中它就像
// configure the locator somewhere early
UnityServiceLocator locator = new UnityServiceLocator( container );
ServiceLocator.SetLocatorProvider( () => locator );
...
// get the container anywhere
var container = ServiceLocator.Current.GetInstance<IUnityContainer>();
关于定位器是否是反模式的讨论超出了范围。在我看来 - 它不是，至少不比整个IoC更“反模式”。