SSH三大框架整合之后的区别

第一，struts与spring

struts2单独使用时action由struts2自己负责创建；与spring集成时，action实例由spring负责创建。这导致在两种情况下struts.xml配置文件的略微差异。

假如：LoginAction在包cn.edu.jlu.cs.action中。

1. struts2单独使用时，action的class属性为LoginAction的全路径名，如下：
               ...
<action name="login" class="cn.edu.jlu.cs.action.LoginAction">
           <result name="studentSuccess">
                /student/studentindex.jsp
           </result>
               ...
2. struts2与spring集成时，class属性是spring的applicationContext.xml中配置的bean的id属性值。
---------------------------------------------------------------------------------------
//struts.xml
               ...
<action name="login" class="LoginAction">
           <result name="studentSuccess">
                /student/studentindex.jsp
           </result>
               ...
----------------------------------------------------------------------------------------
//applicationContext.xml
               ...
<bean id="LoginAction" class="cn.edu.jlu.cs.action.LoginAction" />
               ...
----------------------------------------------------------------------------------------

struts2-spring-plugin-2.1.6.jar这个插件在产生action的时候，会自动的按照名字把action的属性注入进去，

即使不在spring配置文件中为相关的action(bean)注入属性或者在action类中用注解注入，

它也会按照action类中属性的名字从当前容器（？？Spring）中找有没有这个名字的bean并注入进来，或者显示的给定一个名字注入。

所以action的id(spring配置文件中的)不要和它类里边的变量名相同

如果在struts.xml文件中配置action的class是指向action的实际类，那么action的产生由struts控制，

此时action类中的相关变量会按照名称从容器中注入一个相应的bean，如果找不到对应名称的bean，一旦调用这个action就会出错，

但是如果此时为变量加上一个@Resource注解，struts容器产生过action后就会从Spring容器中找相应的bean注入。

如果class指向的是一个伪控制器(对应spring配置文件中action的bean)，那么action的产生由spring控制。

此时action类中的相关变量··必须··用注解@Resource或者xml的方式自定义注入相应的bean，不象之前会按照名字从spring容器中自动查找注入bean，

否则程序运行出错

————————————————————————————————————————————————————————————————————————

第二：Spring与hibernate整合之后

spring提供的是框架级的事务管理，在你使用session.beginTransaction();或tx.commit();的时候就是使用了hibernate的API，这就叫你的代码和hibernate耦合了。如果日后想用JTA或JPA来代替hibernate做持久化工作，你会发现这是一项艰巨的任务——太多代码要改了，几乎要把session.beginTransaction()或tx.commit()的代码都改掉。如果使用了spring的事务控制，你不再需要在代码中使用hibernate的API了，同样是用JTA或JPA来代替hibernate，只需要修改spring的配置文件就可以替换了持久层框架。这样的解决方案是不是十分优雅？这就是spring的魅力所在。当然你可能说“hibernate工作好好的，我为什么要替换持久层框架？”。这个问题很难回答，要套用一句俗语来回答就是：“无论多微小的概率，只要有机会发生的事，就肯定会发生！”当有一天因为hibernate出现不能解决的BUG，或者第三方数据库没有提供jdbc支持而你又必须使用，这时候就有必要替换hibernate了。话说回来，如果你确信自己不会替换hibernate，这样要不要和spring整合都是没所谓的，只是你没有遵从目前的最佳实践罢了。