Autofac 是一款超赞的 .NET IoC 容器 ，在众多性能测评中，它也是表现最优秀的一个。它管理类之间的依赖关系, 从而使 应用在规模及复杂性增长的情况下依然可以轻易地修改 。它的实现方式是将常规的.net类当做 组件 处理。

简单的性能测试

在 LINQPad 中，我们可以很容易 的 构建出一个测试环境（需要引入 Microsoft.Extensions.DependencyInjection 和 Autofac.Extensions.DependencyInjection 组件）：

写一些简单的性能进行测试代码：

在 LINQPad 中对上述代码进行一万次、十万次、百万次三个量级的测试，得出以下报表（纵轴单位为“毫秒”）：

从统计图中可以看到，即便是最耗时的 Transient 对象，百万级别创建的时间消耗也不到 400 毫秒。这说明，大多数情况下 Autofac 之类的 IoC 容器不会成为应用的性能瓶颈。

构造函数 爆炸

当一个系统不断完善，业务在底层会被不断拆分为小的 Service ，然后在顶层（应用层或表现层）组装以完成功能。这表示在 Controller 中我们需要注入大量的 Service 才能保证功能完备。如果我们需要的对象通过构造函数注入，那么就会造成该构造函数的参数多到爆炸。

nopCommerce 是一个 ASP.NET 开发的电子商城系统，具备商城该有的各种功能和特性。在 ShoppingCartController 中你可以看到以下代码：

构造函数爆炸的性能问题

即便参数再多，在感官上也只是一个强迫症的问题。但构造函数爆炸所造成的影响不仅仅只是看上去没那么舒服而已。当我们注入一个对象时，IoC 容器会保证该对象 以及其依赖的对象 已经被正确初始化。所以我们不能简单的根据注入对象的数量来判断性能消耗，因为很有可能某个接口的实现依赖了数个其他对象。

当我们访问一个网页时，只会用到 Controller 中的某一个方法，通常，该方法不会对所有注入的对象都产生依赖。这也意味着我们创建了大量非必要的对象，为内存和 GC 造成了压力。

在 ASP.NET Core 中解决构造函数爆炸问题

ASP.NET Core 提供了一个名为 FromServicesAttribute 的属性来帮助解决必须在构造函数中注入依赖的问题。我们可以为 Action 的参数增加此属性，将所需的依赖注入进来：

这当然解决了构造函数爆炸的问题，很好。但同时，该方案也让方法的参数变得复杂也为单元测试留下了障碍，依旧不够完美。

使用 IServiceProvider 解决构造函数爆炸问题

在依赖注入容器中包含的所有对象都可以通过 IServiceProvider 获取到。基于该特性可以实现依赖对象的按需加载功能：

以上代码在 MyService 的构造函数中输出了创建日志。 MyController 类型中通过 LazyGetRequiredService 方法实现了 MyService 的按需加载，构造函数也只剩下一个 IServiceProvider 对象。以上代码会产生下面的输出：

可以看到，在调用不依赖 MyService 的方法 NoCallMethod 时， MyService 并没有被创建。直到 CallMethod 被调用后用到了 MyService 时，它才被创建。

向 Volo.Abp 学习

Volo.Abp 在 4.2.0 版本中加入了一个新的接口： IAbpLazyServiceProvider 。

其实现同样采用 IServiceProvider 创建对象，同时使用了字典来保存对实例的引用。如果你和我一样使用 Abp 开发代码，那么 LazyServiceProvider 值得尝试。