控制反转（IOC）的理解

    控制反转模式是当今J2EE架构中常用到的模式之一，它符合好莱坞法则:不要调用我，我会调用你。在没有运用IOC的时候，我们一般都是通过工厂来管理对象，当我们需要一个对象的时候，我们通过工厂来创建它，这样就造成了业务代码和工厂的耦合,并且更重要的是需要我们自己来管理对象的生命周期，这样非常繁琐，所以如果我们运用IOC的话，不仅可以解除业务代码与工厂的耦合，而且不用我们进行生命周期管理，大大的减少了编码的工作量。如何实现IOC，现在大概有以下两种方式：
     第一：查找实现。此种实现方法需要一个注册表，当我们需要什么对象的时候，我们就去注册表里查找，不需要自己去创建。因为需要的对象是框架或者是容器帮我们管理的，这时就不需要我们来负责对象的生存周期等的问题。所以生存周期管理也就成了一个容器的必备的能力之一。比如EJB，它就是通过JNDI来查找我们需要的对象的。这样虽然使得我们不需要管理对象的生命周期，但是同时我们的业务代码还是和具体的注册表API相耦合，所以此种办法没有完全解耦。为了实现完全的POJO编程模型，需要采用以下的IOC方式（DI）。
     第二：依赖注射（DI），目前比较流行的是此种实现。依赖注射要求我们只需要声明要用到什么样子的对象，然后设置JavaBean的setter方法就OK了，在我们需要用到对象的时候，容器会帮助我们把需要的对象设置进来。或者也可以通过有参构造器来进行注射，通过依赖注射，我们的业务代码就不需要与具体的容器或者是框架耦合，我们可以完全采用POJO的编程模型。因为我们的业务代码没有与任何的容器相耦合，这样就可以使得代码可以在容器内或者容器外都可以运行，从而提高了复用性和可移植性，同时我们的测试也很容易实现。由此可见IOC给我们的开发带来的是革命性的变化。使得我们的业务代码与具体的容器的耦合度降到了最低的同时，也给我们的测试工作带来了便利。

评论

7 楼 xulongfa 2009-02-11  

引用

[img][/img][url][/url][flash=200,200][/flash]

6 楼 狂放不羁 2008-10-31  

iampurse 写道

其实JNDI只是依赖于JDK   而IOC则依赖框架。   我想问你你的IOC怎么移植?   要说移植的话，就只有SOAP勒。    而且IOC的内部实现其实也并没有解耦。   只是我们用起来感觉是解耦的。

不同的框架通过不同的方式实现了IOC，IOC只是给我们应用程序最大化的解耦，无论你用什么IOC容器，应用程序组件之间是最大化解耦的，组件之间都是通过接口通信。不过如果你首先用spring IOC容器组装了你的系统服务的话，那么当你移植到比如piccontainer,那么也许会改变一些东西，因为你spring ioc容器，我一般用setter注入，而piccontainer要constructor来注入。

不管IOC容器内部有没有解耦，IOC的意图是让我们自己写的组件之间解耦。

这是我的理解。

5 楼 iampurse 2008-10-31  

  其实JNDI只是依赖于JDK
  而IOC则依赖框架。
  我想问你你的IOC怎么移植?
  要说移植的话，就只有SOAP勒。
   而且IOC的内部实现其实也并没有解耦。
  只是我们用起来感觉是解耦的。

4 楼 狂放不羁 2008-10-31  

iampurse 写道

你看过IOC的内部实现么? 而且IOC是依赖于框架。

应该说是框架实现IOC模式。比如piccontainer,spring等，都是一个支持IOC的容器。依赖注入，依赖查找都是IOC模式。

3 楼 iampurse 2008-10-31  

你看过IOC的内部实现么?

而且IOC是依赖于框架。

2 楼 chucai 2008-04-08  

我的一些不成熟的意见：
    IOC很强大。但万物有优点，就有缺点。关于依赖注入，有个不好的就是，如果你忘记了注入某个属性，程序是不会提醒你的。所以，我个人觉得，在这方面有注意。

1 楼 422232121 2008-04-08  

我才搞定呢，和我想的差不多吧。