控制反转和依赖注入

控制反转和依赖注入

IoC实现由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控，控制权由应用代码中转到
了外部容器，控制权的转移，是所谓控制反转。实际上真正的IoC有两种实现方式DI和DL

可供选择的IoC 容器: Apache Avalon、PicoContainer 和 HiveMind。Avalon 从没怎么流行，尽管它很强大而且有很长的历史。Avalon相当的重和复杂，并且看起来比新的IoC解决方案更具侵入性。PicoContainer是一个轻量级而且更强调通过构造函数表达依赖性而不是JavaBean 属性。 与Spring不同，它的设计允许每个类型一个对象的定义(可能是因为它拒绝任何Java代码外的元数据导致的局限性)

Martin Fowler给IoC起更为直观的名字：Dependency Injection依赖注射DI。创建被调用者实例的工作通常由Spring容器来完成，然后注入调用者，因此也称为依赖注入

< bean id=“bb” class=“com.yan.Person” p:birth-ref=“now”/>

针对Person属性birth由容器负责调用Person对象的setBirth将now对象设置进去

IoC和DI的区别

IoC—Inversion of Control 控制反转意味着将设计好的对象交给容器控制，而不是传统的在你对象内部直接控制。IoC容器来控制对象的创建，主要控制了外部资源获取（不仅仅是对象，也包括文件）；由容器查找及注入以来对象，对象只说被动接受依赖对象，所以反转；依赖对象的获取反转了
DI—Dependency Injection依赖注入：是组件之间依赖关系由容器在运行期决定。通俗的说，由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。应用程序依赖于IoC容器；IoC容器注入应用程序某个对象，应用程序依赖的对象；注入某个对象所需要的外部资源（对象、资源、常亮数据）

Spring和EJB的比较

相对于EJB来说，Spring是一个轻量级的JavaEE应用开发框架，使把各个技术层次之间的风险降低。EJB
就是企业级JavaBean。EJB2是重量级，运行必须有对应的容器。EJB3使用JPA已经偏向于轻量级
EJB的内聚性较强，内聚性的白盒特征使我们必须放弃一部分可控性而去信任容器能力。而Spring则是考
虑如何“不造轮子”，如何更好的组装这些轮子，让他们更好的转动

IoC/DI模式的优点

颠覆了“使用对象之前必须创建” 的基本Java语言定律 ，降低了模块之间的耦合度，提高了应用的灵活性和代码重用度。
使用IoC模式，完全在一个抽象层次进行描述和技术架构，因此，IoC模式可以为容器、框架之类的软件实现提供了具体的实现手段

Bean的生命周期

init-method=”方法名称” 老方法是实现一个接口Spring的InitializingBean为bean提供了定义初始化方法的方式。InitializingBean是一个接口，它仅仅包含一个方法：afterPropertiesSet()。这个方法在对象创
建完毕(构造器)，然后执行setXXX方法后自动执行,目前建议采用init-method配置即可，不用实现接口，主要可以定义一些初始化动作，这个方法在整个对象的生命周期中运行且只运行一次.方法签名中可以返回任意类型，允许抛出异常,但是不能包含参数
Spring要求init-method是一个无参数的方法，如果init-method指定的方法中有参数，那么Spring将会
抛出java.lang.NoSuchMethodException
init-method指定的方法可以是public、protected以及private的，并且方法也可以是final的。
init-method指定的方法可以是声明为抛出异常的
如果在init-method方法中抛出了异常，那么Spring将中止这个Bean的后续处理，并且抛出一个
org.springframework.beans.factory.BeanCreationException异常。
destroy-method配置对应DisposableBean接口,可以定义一个在对象销毁之前执行的方法，可以用于进
行资源的释放… 这个方法在整个对象的生命周期中运行且只运行一次.方法规则同init-method配置