一旦了解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子句和
readonly关键字的组合，因此可以确保依赖项可用。
如果需要短暂的对象，请使用Abstract Factory
使用构造函数注入注入的依赖关系往往是长期存在的，但是有时您需要一个短暂的对象，或者基于仅在运行时已知的值来构建依赖关系。
请参阅此以获取更多信息。
仅在最后负责的时刻撰写
使对象解耦，直到最后。通常，您可以等待并在应用程序的入口点连接所有内容。这称为 合成根 。
此处有更多详细信息：
- 我应该在哪里使用Ninject 2+进行注入（以及如何布置模块？）
- 设计-使用Windsor时应在哪里注册对象
使用立面简化
如果您觉得由此产生的API对于新手用户来说太复杂了，则可以始终提供一些封装常见依赖项组合的Facade类。
为了提供具有高度可发现性的灵活立面，您可以考虑提供Fluent Builders。像这样：
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类封装了许多不同的依赖项，那么我希望很清楚，它将在提供可扩展性的同时提供适当的默认值。
FWIW，在写了这个答案很长时间之后，我扩展了本文的概念，并撰写了一篇有关DI友好库的较长博客文章，以及一篇关于DI友好框架的随笔文章。
