什么是依赖注入？

使依赖注入概念易于理解.我们举一个开关按钮来切换(打开/关闭)灯泡.

没有依赖注入

开关需要事先知道我连接的灯泡(硬编码依赖).所以,

开关 - > PermanentBulb //开关直接连接到永久灯泡,测试不容易

Switch(){
PermanentBulb = new Bulb();
PermanentBulb.Toggle();
}

使用依赖注入

Switch只知道我需要打开/关闭哪个Bulb传递给我.所以,

开关 - > Bulb1或Bulb2 OR NightBulb(注入依赖)

Switch(AnyBulb){ //pass it whichever bulb you like
AnyBulb.Toggle();
}

修改开关和灯泡的詹姆斯示例:

public class SwitchTest { 
  TestToggleBulb() { 
    MockBulb mockbulb = new MockBulb(); 

    // MockBulb is a subclass of Bulb, so we can 
    // "inject" it here: 
    Switch switch = new Switch(mockBulb); 

    switch.ToggleBulb(); 
    mockBulb.AssertToggleWasCalled(); 
  } 
}

public class Switch { 
  private Bulb myBulb; 

  public Switch() { 
    myBulb = new Bulb(); 
  } 

  public Switch(Bulb useThisBulbInstead) { 
    myBulb = useThisBulbInstead; 
  } 

  public void ToggleBulb() { 
    ... 
    myBulb.Toggle(); 
    ... 
  } 
}`

什么是依赖注入(DI)？

正如其他人所说,依赖注入(DI)消除了我们感兴趣的类(消费者类)所依赖的其他对象实例(在UML意义上)的直接创建和生命管理的责任.这些实例通常作为构造函数参数或通过属性设置器传递给我们的使用者类(依赖对象实例化和传递给使用者类的管理通常由控制反转(IoC)容器执行,但这是另一个主题) .

DI,DIP和SOLID

具体来说,在Robert C Martin的面向对象设计的SOLID原则的范例中,DI是依赖性倒置原则(DIP)的可能实现之一.所述DIP是D所述的SOLID咒语 -其他DIP实现包括了服务定位器,和插件图案.

拨码的目标是去耦紧,具体依赖类之间,而是,由抽象,其可以通过一个来实现的装置松开联接interface,abstract class或者pure virtual class,取决于所使用的语言和方法.

如果没有DIP,我们的代码(我将其称为"消费类")直接耦合到具体的依赖关系,并且通常还有责任知道如何获取和管理此依赖关系的实例,即概念上:

"I need to create/use a Foo and invoke method `GetBar()`"

在应用DIP之后,要求被放宽,并且Foo已经消除了获得和管理依赖关系生命周期的顾虑:

"I need to invoke something which offers `GetBar()`"

为什么要使用DIP(和DI)？

以这种方式解耦类之间的依赖关系允许用其他实现轻松替换这些依赖类,这些实现也满足抽象的先决条件(例如,可以使用相同接口的另一个实现来切换依赖性).此外,正如其他人所提到的,通过DIP解耦类的最常见原因可能是允许单独测试消耗类,因为这些相同的依赖关系现在可以被存根和/或模拟.

DI的一个结果是依赖对象实例的生命周期管理不再由消费类控制,因为依赖对象现在被传递到消费类(通过构造函数或setter注入).

这可以通过不同方式查看:

如果需要保留使用类对依赖项的生命周期控制,则可以通过将用于创建依赖项类实例的(抽象)工厂注入到使用者类中来重新建立控制.消费者将能够Create根据需要通过工厂获取实例,并在完成后处理这些实例.

或者,依赖关系实例的生命周期控制可以放弃到IoC容器(更多关于此内容).

何时使用DI？

在可能需要将依赖项替换为等效实现的情况下,

任何时候你需要单独测试一个类的方法,而不依赖于它的依赖关系,

如果依赖关系的生命周期的不确定性可能需要实验(例如,嘿,MyDepClass是线程安全的 - 如果我们将它作为单例并将相同的实例注入所有消费者,会怎么样？)

例

这是一个简单的C#实现.鉴于以下消费类:

public class MyLogger
{
   public void LogRecord(string somethingToLog)
   {
      Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
   }
}

虽然看似无害,但它对另外static两个类有两个依赖关系,System.DateTime并且System.Console不仅限制了日志记录输出选项(如果没有人在观察,则记录到控制台将毫无价值),但更糟糕的是,鉴于对依赖性的依赖,很难自动测试一个非确定性的系统时钟.

然而,我们可以DIP通过抽象出时间戳作为依赖关系的问题,并MyLogger仅仅耦合到一个简单的接口来应用于这个类:

public interface IClock
{
    DateTime Now { get; }
}

我们也可以放松对Console抽象的依赖,比如a TextWriter.依赖注入通常实现为constructor注入(将依赖项的抽象作为参数传递给消费类的构造函数)或Setter Injection(通过setXyz()setter 传递依赖项或使用已{set;}定义的.Net属性).构造函数注入是首选,因为这可以保证类在构造之后处于正确的状态,并允许将内部依赖项字段标记为readonly(C#)或final(Java).所以在上面的例子中使用构造函数注入,这给我们留下了:

public class MyLogger : ILogger // Others will depend on our logger.
{
    private readonly TextWriter _output;
    private readonly IClock _clock;

    // Dependencies are injected through the constructor
    public MyLogger(TextWriter stream, IClock clock)
    {
        _output = stream;
        _clock = clock;
    }

    public void LogRecord(string somethingToLog)
    {
        // We can now use our dependencies through the abstraction 
        // and without knowledge of the lifespans of the dependencies
        _output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
    }
}

(Clock需要提供具体内容,当然可以恢复DateTime.Now,并且两个依赖项需要由IoC容器通过构造函数注入提供)

可以构建自动化单元测试,这可以明确证明我们的记录器工作正常,因为我们现在可以控制依赖关系 - 时间,我们可以监视书面输出:

[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
    // Arrange
    var mockClock = new Mock();
    mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
    var fakeConsole = new StringWriter();

    // Act
    new MyLogger(fakeConsole, mockClock.Object)
        .LogRecord("Foo");

    // Assert
    Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
}

下一步

依赖注入总是与控制反转容器(IoC)相关联,注入(提供)具体的依赖实例,以及管理生命周期实例.在配置/引导过程中,IoC容器允许定义以下内容:

每个抽象和配置的具体实现之间的映射(例如"消费者请求的任何时候IBar,返回一个ConcreteBar实例")

可以为每个依赖项的生命周期管理设置策略,例如为每个使用者实例创建新对象,在所有使用者之间共享单个依赖项实例,仅在同一个线程上共享相同的依赖项实例,等等.

在.Net中,IoC容器知道诸如此类的协议IDisposable,并将Disposing根据配置的生命周期管理承担依赖关系的责任.

通常,一旦配置/引导IoC容器,它们就会在后台无缝运行,允许编码器专注于手头的代码,而不是担心依赖性.

DI友好代码的关键是避免类的静态耦合,而不是使用new()来创建依赖项

按照上面的例子,依赖关系的解耦确实需要一些设计工作,对于开发人员来说,需要一种范式转换来直接打破new依赖关系的习惯,而是信任容器来管理依赖关系.

但好处很多,特别是在彻底测试你感兴趣的课程的能力.

注意:new ..()POCO/POJO /序列化DTO /实体图/匿名JSON投影等的创建/映射/投影(通过) - 即"仅数据"类或记录 - 从方法中使用或返回不被视为依赖性(在UML意义)并且不受DI的影响.利用new项目,这些仅仅是罚款.

依赖注入(DI)的重点是保持应用程序源代码的清洁和稳定:

清除依赖初始化代码

无论使用何种依赖性都稳定

实际上,每种设计模式都会将问题分开,以使将来的更改影响最小文件.

DI的特定域是依赖配置和初始化的委托.

示例:带有shell脚本的DI

如果您偶尔在Java之外工作,请回想一下source在许多脚本语言中经常使用的方法(Shell,Tcl等,甚至import是Python用于此目的).

考虑简单的dependent.sh脚本:

#!/bin/sh
# Dependent
touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

该脚本是依赖的:它不会自己成功执行(archive_files未定义).

您archive_files在archive_files_zip.sh实现脚本中定义(zip在本例中使用):

#!/bin/sh
# Dependency
function archive_files {
    zip files.zip "$@"
}

而不是source直接在依赖的实现脚本中使用injector.sh"容器"来包装"组件":

#!/bin/sh 
# Injector
source ./archive_files_zip.sh
source ./dependent.sh

该archive_files 依赖刚刚被注入到相关的脚本.

您可以注入archive_files使用tar或实现的依赖项xz.

示例:删除DI

如果dependent.sh脚本直接使用依赖项,则该方法将被称为依赖项查找(与依赖项注入相反):

#!/bin/sh
# Dependent

# dependency look-up
source ./archive_files_zip.sh

touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

现在的问题是依赖"组件"必须自己执行初始化.

"组件"的源代码既不干净也不稳定,因为依赖关系初始化的每次更改都需要"组件"的源代码文件的新版本.

最后的话

DI并不像Java框架那样受到重视和普及.

但这是分解以下问题的一般方法:

应用程序开发(单一源代码发布生命周期)

应用程序部署(具有独立生命周期的多个目标环境)

仅使用配置依赖项查找没有帮助,因为每个依赖项(例如,新的身份验证类型)以及受支持的依赖项类型(例如,新数据库类型)的配置参数的数量可能会发生变化.

所有上述答案都很好,我的目的是以简单的方式解释这个概念,这样没有编程知识的人也可以理解概念

依赖注入是帮助我们以更简单的方式创建复杂系统的设计模式之一.

我们可以在日常生活中看到这种模式的广泛应用.一些例子是录音机,VCD,CD驱动器等.

上图是20世纪中期卷轴式便携式录音机的图像.来源.

录音机的主要目的是录制或播放声音.

在设计系统时,需要卷轴来录制或播放声音或音乐.设计该系统有两种可能性

我们可以将卷轴放在机器内

我们可以为卷轴提供挂钩.

如果我们使用第一个,我们需要打开机器来更换卷轴.如果我们选择第二个,即放置一个卷轴,我们通过改变卷轴播放任何音乐都有额外的好处.并且还将功能仅限于播放卷轴中的任何内容.

同样明智的依赖注入是将依赖项外部化以仅关注组件的特定功能的过程,以便独立组件可以耦合在一起以形成复杂系统.

我们通过使用依赖注入实现的主要好处.

高内聚力和松散耦合.

外化依赖,只关注责任.

将事物作为组件并组合起来形成具有高性能的大型系统.

它有助于开发高质量的组件,因为它们是独立开发的,经过适当的测试.

如果一个组件出现故障,它可以帮助用另一个组件替换

现在有一天,这些概念构成了编程世界中众所周知的框架的基础.Spring Angular等是建立在这个概念之上的众所周知的软件框架

依赖注入是用于创建其它对象不知道在编译时依赖于哪一个类将被用于提供该功能或注入性的一个对象的简单方式的对象的实例的图案被称为依赖注入.

依赖注入的示例

以前我们正在编写这样的代码

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

使用依赖注入,依赖注入器将为我们取消实例化

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 

  dependentObject.someMethod();
}

你也可以阅读

控制反转与依赖注入的区别

什么是依赖注入？

依赖注入(DI)意味着解耦彼此依赖的对象.假设对象A依赖于对象B,因此想法是将这些对象彼此分离.我们不需要使用new关键字对对象进行硬编码,而是在编译时尽管在运行时共享对象的依赖关系.如果我们谈论

依赖注入如何在Spring中工作:

我们不需要使用new关键字对对象进行硬编码,而是在配置文件中定义bean依赖关系.弹簧容器将负责连接所有.

控制反转(IOC)

IOC是一个通用概念,它可以用许多不同的方式表达,而依赖注入是IOC的一个具体例子.

两种类型的依赖注入:

构造函数注入

二传手注射

1.基于构造函数的依赖注入:

当容器调用具有许多参数的类构造函数时,完成基于构造函数的DI,每个参数表示对其他类的依赖.

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}

        
  

2.基于setter的依赖注入:

基于setter的DI是在调用无参数构造函数或无参数静态工厂方法来实例化bean之后,通过容器调用bean上的setter方法来完成的.

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }


 
        

注意:对于可选依赖项使用构造函数参数和使用可选依赖项的setter是一个很好的经验法则.请注意,如果我们在setter上使用基于@Required注释的注释,则可以使用setter作为必需的依赖项.

我能想到的最好的比喻是手术室里的外科医生和他的助手,外科医生是主要人员,他的助手在需要时提供各种手术部件,以便外科医生可以专注于他做得最好的事(手术).没有助手,外科医生每次需要时都必须自己拿到组件.

简而言之,DI是一种通过向组件提供依赖组件来消除组件的常见附加责任(负担)的技术.

DI让您更接近单一责任(SR)原则,就像surgeon who can concentrate on surgery.

何时使用DI:我建议在几乎所有生产项目(小/大)中使用DI,特别是在不断变化的商业环境中:)

原因:因为您希望您的代码易于测试,可模拟等,以便您可以快速测试您的更改并将其推向市场.除此之外,为什么你不会有很多很棒的免费工具/框架来支持你在你拥有更多控制权的代码库之旅.

例如,我们有2个类Client和Service.Client将使用Service

public class Service {
    public void doSomeThingInService() {
        // ...
    }
}

没有依赖注入

方式1)

public class Client {
    public void doSomeThingInClient() {
        Service service = new Service();
        service.doSomeThingInService();
    }
}

方式2)

public class Client {
    Service service = new Service();
    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

方式3)

public class Client {
    Service service;
    public Client() {
        service = new Service();
    }
    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

1)2)3)使用

Client client = new Client();
client.doSomeThingInService();

好处

简单

缺点

硬盘测试Client类

当我们改变Service构造函数时,我们需要在所有地方更改代码创建Service对象

使用依赖注入

方法1)构造函数注入

public class Client {
    Service service;

    Client(Service service) {
        this.service = service;
    }

    // Example Client has 2 dependency 
    // Client(Service service, IDatabas database) {
    //    this.service = service;
    //    this.database = database;
    // }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

运用

Client client = new Client(new Service());
// Client client = new Client(new Service(), new SqliteDatabase());
client.doSomeThingInClient();

方式2)塞特犬注射

public class Client {
    Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

运用

Client client = new Client();
client.setService(new Service());
client.doSomeThingInClient();

方式3)接口注入

检查https://en.wikipedia.org/wiki/Dependency_injection

===

现在,这个代码已经跟随Dependency Injection,测试Client类更容易.
但是,我们仍然使用new Service()很多时间,并且在更改Service构造函数时并不好.为了防止它,我们可以使用DI喷射器,如
1)简单的手动Injector

public class Injector {
    public static Service provideService(){
        return new Service();
    }

    public static IDatabase provideDatatBase(){
        return new SqliteDatabase();
    }
    public static ObjectA provideObjectA(){
        return new ObjectA(provideService(...));
    }
}

运用

Service service = Injector.provideService();

2)使用库:适用于Android dagger2

好处

使测试更容易

更改时Service,只需在Injector类中更改它

如果你使用use Constructor Injection,当你看构造函数时Client,你会看到Clientclass有多少依赖

缺点

如果使用use Constructor Injection,Service则在Client创建对象时创建对象,有时我们在Client没有使用的情况下使用类中的函数,Service因此Service浪费了

依赖注入定义

https://en.wikipedia.org/wiki/Dependency_injection

依赖项是可以使用的对象(Service)
注入是将dependency(Service)传递给Client将使用它的依赖对象()

这意味着对象应该只具有执行其工作所需的依赖项,并且依赖项应该很少.此外,对象的依赖关系应该在接口上,而不是在"具体"对象上,如果可能的话.(具体对象是使用关键字new创建的任何对象.)松散耦合可提高可重用性,更易于维护,并允许您轻松提供"模拟"对象来代替昂贵的服务.

"依赖注入"(DI)也称为"控制反转"(IoC),可用作鼓励这种松散耦合的技术.

实施DI有两种主要方法:

构造函数注入

塞特犬注射

构造函数注入

这是将对象依赖项传递给其构造函数的技术.

请注意,构造函数接受接口而不是具体对象.另请注意,如果orderDao参数为null,则抛出异常.这强调了接收有效依赖的重要性.在我看来,构造函数注入是赋予对象依赖性的首选机制.开发人员在调用对象时很清楚需要将哪些依赖关系赋予"Person"对象以便正确执行.

二传手注射

但请考虑以下示例...假设您有一个具有十个没有依赖关系的方法的类,但您添加的新方法确实依赖于IDAO.您可以更改构造函数以使用构造函数注入,但这可能会强制您更改所有构造函数调用.或者,您可以添加一个新的构造函数来获取依赖项,但是开发人员如何轻松地知道何时使用一个构造函数而不是另一个构造函数.最后,如果创建依赖项非常昂贵,为什么它应该只在很少使用的情况下创建并传递给构造函数？"Setter Injection"是另一种DI技术,可用于此类情况.

Setter Injection不会强制将依赖项传递给构造函数.相反,依赖项设置为有需要的对象公开的公共属性.如前所述,这样做的主要动机包括:

支持依赖注入,而无需修改遗留类的构造函数.

允许尽可能晚地创建昂贵的资源或服务,并且仅在需要时创建.

以下是上述代码的示例:

public class Person {
    public Person() {}

    public IDAO Address {
        set { addressdao = value; }
        get {
            if (addressdao == null)
              throw new MemberAccessException("addressdao" +
                             " has not been initialized");
            return addressdao;
        }
    }

    public Address GetAddress() {
       // ... code that uses the addressdao object
       // to fetch address details from the datasource ...
    }

    // Should not be called directly;
    // use the public property instead
    private IDAO addressdao;

我想既然每个人都为DI写过,我想问几个问题.

当你有一个DI的配置,其中所有实际的实现(而不是接口)将被注入一个类(例如服务到控制器)为什么不是某种硬编码？

如果我想在运行时更改对象怎么办？例如,我的配置已经说明当我实例化MyController时,将FileLogger注入ILogger.但我可能想注入DatabaseLogger.

每次我想要更改我的AClass需要的对象时,我现在需要查看两个地方 - 类本身和配置文件.这怎么能让生活更轻松？

如果没有注入AClass的Aproperty,那么嘲笑它是否更难？

回到第一个问题.如果使用new object()是坏的,我们怎么注入实现而不是接口？我想你们很多人都在说我们实际上正在注入接口,但配置会让你指定该接口的实现.不在运行时..它在编译期间是硬编码的.

这是基于@Adam N发布的答案.

为什么PersonService不再需要担心GroupMembershipService？您刚才提到GroupMembership有多个依赖的东西(对象/属性).如果PService中需要GMService,您可以将其作为属性.无论你是否注射它,你都可以嘲笑它.我唯一希望它被注入的是GMService是否有更具体的子类,直到运行时才能知道.然后你想要注入子类.或者,如果您想将其用作单身或原型.说实话,配置文件的所有内容都是硬编码的,只要它在编译时要注入的类型(接口)的子类.

编辑

Jose Maria Arranz对DI的好评

DI通过消除确定依赖方向的任何需要并写入任何胶水代码来增加内聚力.

假.依赖关系的方向是XML形式或注释,您的依赖关系被编写为XML代码和注释.XML和注释是源代码.

DI通过使所有组件模块化(即可替换)并且彼此具有良好定义的接口来减少耦合.

假.您不需要DI框架来构建基于接口的模块化代码.

关于可替换:使用非常简单的.properties存档和Class.forName,您可以定义类可以更改.如果可以更改任何类的代码,Java不适合您,请使用脚本语言.顺便说一下:如果不重新编译,就无法更改注释.

在我看来,DI框架有一个唯一的原因:锅炉板减少.使用完善的工厂系统,您可以做同样的,更加可控和更可预测的DI框架,DI框架承诺减少代码(XML和注释也是源代码).问题是这种锅炉板减少在非常简单的情况下是真实的(一个实例 - 每个类和类似),有时在现实世界中挑选适当的服务对象并不像将类映射到单个对象那么容易.

流行的答案是无益的,因为它们以一种无用的方式定义依赖注入.让我们同意,"依赖"是指我们的对象X需要的一些预先存在的其他对象.但是,当我们说时,我们并没有说我们正在做"依赖注入"

$foo = Foo->new($bar);

我们只是将调用传递给构造函数.自建造者发明以来,我们一直在做这个.

"依赖注入"被认为是一种"控制反转",这意味着某些逻辑被从调用者中取出.当调用者传入参数时不是这种情况,因此如果是DI,则DI不会意味着控制反转.

DI表示调用者和构造函数之间存在一个中间级别,用于管理依赖关系.Makefile是依赖注入的一个简单示例."调用者"是在命令行上键入"make bar"的人,"构造函数"是编译器.Makefile指定bar依赖于foo,它执行a

gcc -c foo.cpp; gcc -c bar.cpp

在做之前

gcc foo.o bar.o -o bar

输入"make bar"的人不需要知道bar依赖于foo.依赖是在"make bar"和gcc之间注入的.

中间级别的主要目的不仅仅是将依赖项传递给构造函数,而是将所有依赖项列在一个位置,并将它们隐藏在编码器中(而不是让编码器提供它们).

通常,中间级别为构造的对象提供工厂,这些工具必须提供每个请求的对象类型必须满足的角色.这是因为通过具有隐藏构造细节的中间级别,您已经承担了工厂施加的抽象惩罚,因此您不妨使用工厂.

依赖注入意味着一部分代码(例如一个类)以一种模块化方式访问依赖项(代码的其他部分,例如其他类,它依赖)的方式(实际上是任意方式),而不需要对它们进行硬编码(所以它们可以自由地改变或被覆盖,甚至可以根据需要在其他时间加载

(和ps,是的,它已成为一个过于夸张的25美元名称,一个相当简单的概念),我的.25美分

我知道已有很多答案,但我发现这非常有用:http://tutorials.jenkov.com/dependency-injection/index.html

没有依赖性:

public class MyDao {

  protected DataSource dataSource =
    new DataSourceImpl("driver", "url", "user", "password");

  //data access methods...
  public Person readPerson(int primaryKey) {...}

}

相关性:

public class MyDao {

  protected DataSource dataSource = null;

  public MyDao(String driver, String url, String user, String
 password){
    this.dataSource = new DataSourceImpl(driver, url, user, password);
  }

  //data access methods...
  public Person readPerson(int primaryKey)
  {...}

}

注意DataSourceImpl实例化如何移动到构造函数中.构造函数接受四个参数,这四个参数是需要的四个值DataSourceImpl.尽管MyDao该类仍依赖于这四个值,但它本身不再满足这些依赖性.它们由创建MyDao实例的任何类提供.

依赖注入是通常被称为"依赖性混淆"要求的一种可能的解决方案.依赖性混淆是一种将"明显"性质从提供依赖性到需要它的类的过程中带走的方法,并因此以某种方式模糊化对所述类的所述依赖性的提供.这不一定是坏事.事实上,通过模糊向类提供依赖的方式,类之外的东西负责创建依赖,这意味着,在各种场景中,可以向类提供不同的依赖实现,而不进行任何更改上课.这非常适合在生产和测试模式之间切换(例如,使用'模拟'服务依赖性).

不幸的是,糟糕的是,有些人认为你需要一个专门的框架,这样做的依赖模糊处理,你是莫名其妙地"较小"的程序员,如果你选择不使用特定的框架来做到这一点.许多人认为另一个非常令人不安的神话是依赖注入是实现依赖性混淆的唯一方法.这显然是历史性的,显然是100%错误的,但是你会难以说服某些人为依赖性混淆要求提供依赖注入的替代方案.

程序员已经理解了多年来的依赖性混淆要求,并且在构思依赖性注入之前和之后已经发展了许多替代解决方案.有工厂模式,但是使用ThreadLocal还有很多选项,不需要注入特定实例 - 依赖项有效地注入到线程中,这有利于使对象可用(通过方便的静态getter方法)到任何类需要它而不必向需要它的类添加注释,并设置复杂的XML"粘合剂"来​​实现它.当持久性需要依赖项(JPA/JDO或其他)时,它允许您更容易实现"转换持久性",并且域模型和业务模型类完全由POJO组成(即没有特定于框架/在注释中锁定).

来自本书,'有良好基础的Java开发人员:Java 7的重要技术和多语言编程

DI是IoC的一种特殊形式,其中查找依赖关系的过程超出了当前正在执行的代码的直接控制.