理解了DI是关于模式和原则而不是技术，实际上这很简单。
要以与DI容器无关的方式设计API，请遵循以下一般原则：
针对接口编程，而不是实现
这个原则实际上是摘自《设计模式》（尽管是从记忆中摘录的），但它应该始终是您的真正目标。 DI只是实现该目标的方法。
应用好莱坞原则
在DI方面，好莱坞原则的意思是：不要调用DI容器，容器会调用你。
永远不要直接通过从代码内部调用容器来请求依赖项。通过使用构造函数注入隐式地请求依赖项。
使用构造函数注入
当需要依赖项时，通过构造函数静态地请求它：
public class Service : IService
{
private readonly ISomeDependency dep;
public Service(ISomeDependency dep)
{
if (dep == null)
{
throw new ArgumentNullException("dep");
}
this.dep = dep;
}
public ISomeDependency Dependency
{
get { return this.dep; }
}
}
注意Service类如何保证其不变式。一旦创建实例，由于Guard Clause和readonly关键字的组合，依赖项保证可用。
如果需要短暂的对象，请使用抽象工厂
使用构造函数注入的依赖项往往具有长生命周期，但有时需要一个短生命周期的对象或根据仅在运行时已知的值构建依赖项。
请参见此处以获取更多信息。
仅在最后负责时构成
将对象保持解耦，直到最后才组合。通常，您可以等待并在应用程序的入口点中连接所有内容。这称为组合根。
更多详细信息请看：
使用Facade简化
如果您觉得为初学者用户提供的API变得太复杂，可以始终提供一些封装常用依赖项组合的Facade类。
要提供灵活的Facade和高度可发现性，您可以考虑提供流畅构建器。例如：
public class MyFacade
{
private IMyDependency dep;
public MyFacade()
{
this.dep = new DefaultDependency();
}
public MyFacade WithDependency(IMyDependency dependency)
{
this.dep = dependency;
return this;
}
public Foo CreateFoo()
{
return new Foo(this.dep);
}
}
这将允许用户通过编写以下内容来创建默认的Foo
var foo = new MyFacade().CreateFoo();
然而，很容易发现可以提供自定义依赖项，您可以编写
var foo = new MyFacade().WithDependency(new CustomDependency()).CreateFoo();
如果你想象一下MyFacade类封装了很多不同的依赖关系，希望现在清楚了如何提供适当的默认值，同时仍然使可扩展性易于发现。
顺便说一句，在撰写这篇答案后很久，我进一步阐述了这里的概念，并撰写了一篇更长的博客DI-Friendly Libraries，以及一篇关于DI-Friendly Frameworks的配套文章。
