看部电影，透透彻彻理解IoC(你没有理由再迷惑!)

  嗯，这儿没说，但在书中有说。请参看书的 4.10.3 自动装配Bean：

package com.baobaotao.anno;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
    //① 定义一个Service的Bean
@Service
public class LogonService { 
       //② 分别注入LogDao及UserDao的Bean
   @Autowired
   private LogDao logDao;  
   @Autowired
   private UserDao userDao;  
   …
}

   不过我觉得字段注入和setter注入都应归为“属性注入”的范畴，分开说反而不好。
   它们之间的区别仅在于：
   setter注入是Spring调用setter方法完成属性注入，而字段注入是Spring使用Java的反射机制进行属性注入，因此把它们看成是属性注入的两个实现更妥些。

因为IoC确实不够开门见山，因此业界曾进行了广泛的讨论，最终软件界的泰斗级人物Martin Fowler提出了DI（依赖注入：Dependency Injection）的概念用以代替IoC，即让调用类对某一接口实现类的依赖关系由第三方（容器或协作类）注入，以移除调用类对某一接口实现类的依赖。“依赖注入”这个名词显然比“控制反转”直接明了、易于理解。

Inversion of Control is a common phenomenon that you come across when extending frameworks. Indeed it's often seen as a defining characteristic of a framework.

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

There are various ways you can plug your code in to be called. In the ruby example above, we invoke a bind method on the text entry field that passes an event name and a Closure as an argument. Whenever the text entry box detects the event, it calls the code in the closure. Using closures like this is very convenient, but many languages don't support them.

Another way to do this is to have the framework define events and have the client code subscribe to these events. .NET is a good example of a platform that has language features to allow people to declare events on widgets. You can then bind a method to the event by using a delegate.

The above approaches (they are really the same) work well for single cases, but sometimes you want to combine several required method calls in a single unit of extension. In this case the framework can define an interface that a client code must implement for the relevant calls.

There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use. The name is somewhat confusing (and ironic) since IoC containers are generally regarded as a competitor to EJB, yet EJB uses inversion of control just as much (if not more).

When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.

The question, is what aspect of control are they inverting? When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like "Enter name", "enter address"; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.

For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

I'm going to start by talking about the various forms of dependency injection, but I'll point out now that that's not the only way of removing the dependency from the application class to the plugin implementation. The other pattern you can use to do this is Service Locator, and I'll discuss that after I'm done with explaining Dependency Injection.

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

    哈哈，downpour，你才给我良好啊，我是想精华哦。
    大意同意你的分析，downpour一向是有理有据啊
    这么说吧，IoC的概念大于DI，可以说DI是IoC，但是，不能说IoC是DI，就象我们可以说，白马是马，但是不能马是白马一样。所以，DI是窄化的IoC,由于Spring IoC主要是接口实现类的注入，因此，如果在Spring这个前提下，说IoC是DI是没有问题的。也在Spring这个背景上下文中，我说Martin Fowler提倡用DI代替IoC也是没有错的，因为这正好和Martin Fowler所说的这句话原意吻合：

如果在Spring这个前提下，说IoC是DI是没有问题的

这个说法，我认为并不是Martin Fowler的本意。Martin Fowler的本意绝不是说DI用以代替IoC，所以我认为你在这里讲的概念和Martin Fowler讲的事情并不一样。







这个是我摘录的Martin Fowler的原话，尤其在讲述IoC和DI之间的误解的地方，我用红色的加粗了。

所以，本文中所谈到的所谓的IoC的类型，纯粹是一个伪命题，至少应该改为DI的类型。



从这里我们可以看到Martin Fowler的原意，就是为了区分开IoC这个generic的概念，才专门为这些所谓实现了IoC功能的Container去构造了一个Dependency Injection。

在上面这段话之后，Martin Fowler紧接着就开始将Forms of Dependency Injection。如下图所示：



大家在这里要注意的是用词：Forms of Dependency Injection。根本不是什么IoC类型，而是DI类型！

综合上面所有的来自Martin Fowler的原话，我们可以得到的结论是：IoC的概念更为宽泛，但它绝不是DI！DI也不是用来代替IoC的，DI是Martin Fowler之后定义出来用以描述那些所谓实现了IoC的Container的一种Pattern，其本意是为了希望大家能够与IoC的概念区分开来。

从本文的内容看，前半部分基本上对IoC描述的比较清楚，不过后半部分，我个人觉得对Martin Fowler的原意有一些曲解。不过总体来说还是很不错的一篇文章，我投了个良好贴。