（一）对Spring和Struts2配合使用的总结。
（详细的框架整合见上一篇博文）
Struts2作为web应用中使用较多的框架具有容易理解便于操作的特点，并且本身在实现上容易上手。实现一个简单的基于Struts2和Spring框架的web应用有以下几步，对于Struts2有：引入核心jar包、配置启动监听器（在web.xml中配置）、创建action（在struts.xml文件中配置，注意命名空间namespace的使用，一般是：”/”）、定义前端页面（html或者jsp（其中在form元素中使用action时候需要写为：xxxaction.action才可完成跳转））、在action类中完成对前端属性的接收（注意几种接收方式、后端的属性名要和前端属性保持一致，并设置setter和getter方法）、进行业务逻辑的处理；
对于在整合中的Spring，首先理解其作用：Spring通过管理action使得Struts2成了一个伪控制器（可以实现较高程度的action业务处理的解耦）；Spring中实现action中业务组件的注入（可以实现较高程度的代码复用，也就是说在Spring容器进行初始化的时候前端请求调用的是Spring容器中的action）。
注意：下面给出查看自己是否使用了Spring中的action的检查方法：在struts.xml文件中查看<action name=”xxx” class=””> 中的class的值，如果是“类名.action名”，那么就说明你没有使用到Spring中的action；如果是“Spring中action注入的Id名”，那么就说明你使用到了。
（二）Spring重点知识。
(1).Spring中的Bean
（下面是引用的老师的讲义，感谢老师的细心总结）：
IOC的解释：IoC 不是一种技术，只是一种思想，其思想是反转资源获取的方向. 应用程序原本是老大，要获取什么资源都是主动出击，但是在IOC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。
IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦
对象耦合
IOC
由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。
我们再来做个试验：把上图中间的IOC容器拿掉，然后再来看看这套系统：
图4 拿掉IOC容器后的系统
我们现在看到的画面，就是我们要实现整个系统所需要完成的全部内容。这时候，A、B、C、D这4个对象之间已经没有了耦合关系，彼此毫无联系，这样的话，当你在实现A的时候，根本无须再去考虑B、C和D了，对象之间的依赖关系已经降低到了最低程度。所以，如果真能实现IOC容器，对于系统开发而言，这将是一件多么美好的事情，参与开发的每一成员只要实现自己的类就可以了，跟别人没有任何关系！这也正是使用在Struts2框架中整合Spring框架的重要意义。
控制反转(IOC)到底为什么要起这么个名字？
例如：软件系统在没有引入IoC容器之前，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在自己手上。
软件系统在引入IoC容器之后，这种情形就完全改变了，由于IoC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IoC容器会主动创建一个对象B注入到对象A需要的地方。
通过前后的对比，我们不难看出来：对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。
- IoC和DI的含义是相同的
IOC也叫依赖注入(DI)
既然IOC是控制反转，那么到底是“哪些方面的控制被反转了呢？”，经过详细地分析和论证后，他得出了答案：“获得依赖对象的过程被反转了”。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。于是，他给“控制反转”取了一个更合适的名字叫做“依赖注入（Dependency Injection）”。他的这个答案，实际上给出了实现IOC的方法：注入。所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
- IoC的含义：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器 （在 Spring 框架中是 IoC 容器）负责将这些联系在一起。
- 举例说明：当我们需要寻找男女朋友时
- 常规情况是遇到心仪的对象后，想尽办法打听她们的兴趣爱好、联系方式等信息，然后想办法认识她们；
这就相当于在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。 【IOC1】
-
- 通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，然后婚介就会按照我们的要求，提供一个对象；这就是简单工厂类 【IOC2】
- 工厂类如果这样写的话，就有一个问题，如果增加了新的对象，那么在工厂类里面也要进行相关的修改了，这样不合理，而java的反射机制可以解决这个问题 【IOC3】
- 利用java的反射机制，就能动态的实例化各种类了。 但是这个程序还是存在一个问题，就是主函数这里需要填入一个完整的类名称，不够方便，所以要增加配置文件来简化 【IOC4】
- 加入配置文件问题就解决了，以后如果要增加新的水果类，都要在这个配置文件里面登记（在配置文件中进行登记表示将该Bean加入到Spring的容器中）。这时我们可以说配置文件可以控制程序的执行，现在看起来有点像spring的ioc了。
- IoC实现的基础是工厂模式，所使用的技术主要是java的反射技术。
- IoC是Spring的核心和基础
（三）spring中进行集合类型的注入。
1.使用props进行datasource的配置可以代替Hiberante中的hibernate.cfg.xml文件，例如：(在applicationContext.xml文件中的配置,在配置sessionFactory中时候进行MySQL数据库中方言等配置示例)
<!-- 加载方言，加载可选项 -->
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.format_sql">true</prop>
<prop key="hibernate.hbm2ddl.auto">update</prop>
</props>
</property>
（四）Bean的作用域。
对于在applicationContext.xml文件中配置bean的时候我们需要注意的是不设置bean的scope时候是单例模式
但是在设置scope = “prototype”时候那么我们产生的是多例模式。
Bean的作用域（即bean中的scope的取值）
Singleton：此实例表明在进行容器的初始化的时候只有一个实例，所有引用某一个bean都是单一的实例。（如同servlet在web容器中的生命周期）。
Prototype：表示每一次前端在请求容器中的对象的时候，容器都返回一个bean对象，，当容器返回之后便不再拥有该实例的控制权，使得该对象自生自灭，这一范围在进行Sturts2和Spring的整合的时候是最常用的。
Rquest：在web应用中很多出现，存在时间和http请求中的request基本一致，并且和上述的prototype的本质基本上一致。
Session：Spring容器会为每个独立的session创建属于自己的全新的class实例，比request scope的bean会存活更长的时间，其他的方面没区别，如果java web中session的生命周期。
(五) 对Spring中的继承的总结。
Spring中允许继承bean的配置
例如：
<bean id=” parentClass” class=”” abstract=”true”>
<property name=“”>xxx</property>
</bean>
<bean id=”xxx” parent=”parentClass”>
<property></property>//表示子类中特有的属性
</bean>
Spring中的继承和java中的区别：{
Spring中可以实现不同类别的继承
Java只可以是同类的
Spring中的子类没有多态的概念
}
对于在A类中设置属性的时候使用的是B类的对象，那么在启动Spring的时候先初始化B类
1478
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
