邢台pc网站开发,临翔区城乡建设局网站,wordpress导出数据字典,产品的推广及宣传思路Autofac 是一款超赞的 .NET IoC 容器 #xff0c;在众多性能测评中#xff0c;它也是表现最优秀的一个。它管理类之间的依赖关系, 从而使 应用在规模及复杂性增长的情况下依然可以轻易地修改。它的实现方式是将常规的.net类当做 组件 处理。简单的性能测试在 LINQPad 中… 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 值得尝试。
