WEB核心IOC篇

ioc概念的理解：(不是技术是一种设计思想)

1. IOC (控制反转)
2.     IoC（Inverse of Control）的字面意思是 控制反转 ，它包括两个内容：
3.     其一是控制 （控制对象的实例化由使用者创建实例变成由容器创建）
4.     其二是反转 （获取依赖对象的方式由使用者主动获取变成等待容器被动注入）
5. 如果你觉得这个概念难以理解，你可以尝试一下理解另外一个对此概念的另外解读:
6. DI( Dependency Injection 依赖注入)这个概念可以用来辅助理解IOC。
7.     即让调用类对某一接口实现类的依赖关系由第三方（容器或协作类）注入，
8.     以移除调用类对某一接口实现类的依赖。“依赖注入”这个名词显然比“控制反转”直接明了、易于理解。

 

 

ioc的注入的类型：

               构造函数注入 

                 属性注入 

                 接口注入

IOC容器的作用。（ioc容器是一种技术，实现ioc思想的一种方式）

      帮助我们完成实体类的实例化，装配,销毁等工作也就说我们常说的管理对象的生命周期。

      IOC容器可以让我们从底层实现类的实例化以及依赖关系的装配等工作中脱离出来。

      更专注于业务逻辑的开发。

 

ioc容器如何将对象纳入容器中进行管理？？

               1.使用配置文件

                    IOC容器使用较多的配置文件应该是xml，使用xml文件描述创建实例，依赖关系是比较常用的手段。

                    不过，很多的框架也使用json数据格式去配置。

                    放到配置文件里的实体类都会被容器管理。   

               2.注解

                     通过特定注解将需要容器管理的实体类进行标记，然后统一扫描对这些类进行实例化，注入依赖。

IOC容器的核心实现原理？？

         一.配置文件的方式

                1.使用xml约定配置项表示bean。

                2.读取xml文件获取创建bean需要的值（类名,属性名,属性值）

                3.使用Java反射技术创bean。

                4.将创建的对象放置到一个代表整个bean容器的map中。

          二.注解的方式

                1.在需要被容器管理的类上添加注解。

                2.使用jave反射扫描带有注解标记的类，取出创建bean实例

                3.将创建的对象放置到一个代表整个bean容器的map中。

         需要注意的是：所有被容器管理的bean的实例默认都是单例的！

什么时候使用注解什么时候使用配置文件呢？

          使用配置文件的场景：

             系统在运行的时候对象的状态可能会改变的，这个时候可以使用配置文件去管理这个bean。

             像数据库连接池，redis等bean的配置，

             我们在应用中如果使用第三方jar包中的bean的时候我们会采用配置的方式，（因为我们不大可能为第三方jar包添加上注解）

        还有自身系统中的某些bean在不同的运行环境下有不同的实例，这个时候配置文件是首选。

          使用注解的场景：

                耦合关系基本不变的使用注解。

                     比如：像各个分层之间的service，web层的module与对应的service，这些bean的关系不会经常变更

                           所有使用注解还是甚好的。

ioc容器在整个架构（我公司的架构）中都做了哪些事情???

               分为两类使用配置文件，使用注解。

               1.配置文件

                    数据源（连接池），redis配置，常用sql对象配置，aop相关配置（事务，角色验证）

               2.注解 

                    所有分层（base,bussiness,web）中的所有service。

                    所有web层中的Module类

参考博客：

http://www.cnblogs.com/xdp-gacl/p/4249939.html

http://blog.csdn.net/wanghao72214/article/details/3969594