服务定位器与依赖注入

dea*_*mon 6 java dependency-injection factory-pattern

我正在审查代码中有很多这样的语句:

private SomeInterface x = Locator.getInstance(SomeInterface.class)
Run Code Online (Sandbox Code Playgroud)

我希望有类似的东西

private SomeInterface x;

@Inject
public Consumer(SomeInterface x){ // constructor
    this.x = x;
}
Run Code Online (Sandbox Code Playgroud)

第一种方法有问题吗?好的,依赖关系并不那么明显,但可以通过配置Locator轻松交换实现.

pla*_*nes 11

Martin Fowler写了一篇关于DI与Locators文章:

对于DI:

  • 更容易确定组件具有哪些依赖项 - 查看构造函数.
  • 组件不依赖于服务定位器,因此如果组件与不同的框架一起使用则没有问题.
  • DI可以使测试更容易,但良好的服务定位器机制将使存根同样可行

反对DI:

  • 更难调试和理解.
  • 一旦配置,组件就无法从注入器请求额外服务.

我个人认为第一个基于定位器的方法没有任何本质上的坏处 - 我想DI确实标准化了,所以如果它可用我将使用它.所有好的想法往往最终都会成为框架,所以这就是这里发生的事情.使用DI,您可以利用其他注释,范围等,而无需滚动自己的代码.而且您的项目使用的定制代码越少,IMO越好.我会把最后一句话留给福勒:

服务定位器和依赖注入之间的选择不如将服务配置与应用程序中的服务使用分离的原则重要.


adt*_*adt 6

第一个例子:x = Locator.getInstance(SomeInterface.class)看起来像Service Locator模式,而http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx检查这篇文章它说服务定位器是一个反对 - 模式,应该避免

而对于第二次使用它很好我喜欢Constructor Injection,它的顺利实现.但我想不使用属性(Java中的annotanitons?)因为任何时候我可能想要更改我正在使用的DI容器,我不想从所有类中删除属性.

  • `@Inject`由Java [JSR-330]标准化(http://www.jcp.org/en/jsr/detail?id=330) (2认同)