Resolve和Register的IContainer来从容器中抽象出内容。我以前试过几次。然后，你可以实现一个Container : IContainer并用你的抽象封装一个实际的IoC容器。我曾试过使用Unity和Castle Windsor。
但是，很快我意识到这真的是一种过度工程。我明白了我试图从抽象中抽象出来，却建立了另一个抽象。这可能对于学习概念来说很好，但在一个真正的项目中，这会让人非常头疼。我强烈建议不要从IoC容器中进行抽象。如果你正确地使用DI原则，改变你的容器将是相当容易的。
代码看起来过于复杂，像：
//I did this mess with Service Locator
var t = ContainerService.Instance.Resolve<IMyType>();
//others could go further with same Service Locator
var t = IoCFactory.Instance.CurrentContainer.Resolve<IMyType>();
//better way, use --> IoC and DI <--
//when a program starts, or a new instance of the context created
var t = Container.Resolve<IMyType>() //this lives at the bottom of the stack
//and then you just pass IMyType to the constructor of other types
//you don't need to call Resolve again in the logical cycle
请参考Ayende的这篇文章。
是的，他们抽象化了控制反转容器。我认为，如果您需要这样做，那么很明显您并不真正理解IoC的全部含义。
正如其他人提到的那样，最好使用构造函数注入。这将解决你的许多问题。
如果你的类直接依赖于IoC容器本身，它往往是使用服务定位器（反）模式的一种变体。在这种情况下，隔离使用服务定位器解析的类型，并使用工厂接口抽象该动态解析。例如，替换为：
public class Foo
{
private MyIoCContainer _container;
public Foo(MyIoCContainer container)
{
this._container = container;
}
public void DoSomething()
{
// have to do this at runtime for whatever reason
var myObj = this._container.Resolve<ISomeType>();
myObj.DoSomething();
myObj.DoSomethingElse();
}
}
public class Foo
{
private IObjFactory _provider;
public Foo(IObjFactory _provider)
{
this._provider = provider;
}
public void DoSomething()
{
var myObj = _provider.GetObj();
myObj.DoSomething();
myObj.DoSomethingElse();
}
}
public interface IObjFactory
{
ISomeType GetObj();
}
IObjFactory，它可以封装构造实现ISomeType的对象的动态运行时特性。如果你从容器/服务定位器中构造许多不同类型的对象，则应该至少拥有与之相对应的*Factory接口（符合接口隔离原则）。请查看Common Service Locator库（GitHub）。(之前位于CodePlex上）。