依赖注入 – 依赖注入的性能问题

在我的分析器报告中,我越来越多地看到依赖注入的基于模拟的测试结果.许多依赖项都是静态的,但是因为我们想要单独测试方法,所以它们会更改为实例成员,如下例所示：

class ShortLivedThing {
   IDependency1 dep1;
   IDependency1 dep2;
   IDependency1 dep3;
   ...

   int TheRealData;

   // Constructor used in production 
   public ShortLivedThing() {
     dep1 = new Dep1(); dep2 = new Dep2(); dep3 = new Dep3();
   }

   // DI for testing 
   public ShortLivedThing(IDependency1 d1,IDependency2 d2,IDependency3 d3) { 
     dep1 = d1(); dep2 = d2(); dep3 = d3();
   }
}

反过来,依赖关系大部分时间都有其他依赖关系,依此类推.每次在测试之外进行方法调用时,这导致(实际上是“静态”)对象树的实例化.每个对象都非常小(只有几个指针),但树效果将其变为不断增加的性能.

我们对于它可以做些什么呢？

在我看来,您需要利用适当的依赖注入框架可以为您提供的功能.不要使用不同的构造逻辑进行测试/生产.

对于弹簧,单次注射仅在容器启动时执行.每次都进行原型注射.每次运行单元测试时,如果正在连接,也会完成全部接线.所以剖析单元测试通常不是一个好主意.

也许你使用的单例范围太少,原型范围太多？ (每次原型=新实例)

弹簧注入的好处是你可以使用范围代理,这意味着你的对象图可能如下所示：

A Singleton
 |
 B Singleton
 |
 C Prototype (per-invocation)
 |
 D Singleton
 |
 E Session scope (web app)
 |
 F Singleton

每个请求只会在每个会话中创建一个C实例和一个E实例. A,B,D和F是单例.如果它不是一个webapp,你默认没有会话范围,但你也可以制作自定义范围(一个窗口桌面应用程序的“Window”范围听起来很酷).这里的线索是,您可以在任何级别“引入”范围,实际上您可以拥有十层单例对象,并突然显示会话作用域. (这可以彻底改变您在分层架构中实现某些交叉功能的方式,但这是一个不同的故事)

我认为这确实可以在DI模型中创建最小的对象.

虽然这是Spring for Java,但我相信其他一些DI框架应该支持类似的功能.也许不是最简约的.