struts 控制用的

hibernate 操作数据库的

spring 用解耦的
详细的说：

STRUTS 在 SSH 框架中起控制的作用 , 其核心是 Controller, 即 ActionServlet, 而 ActionServlet 的核心就是 Struts-confi g.xml. 主要控制逻辑关系的处理 .

hibernate 是数据持久化层 , 是一种新的对象、关系的映射工具 , 提供了从 Java 类到数据表的映射，也提供了数据查询和恢复等机制 , 大大减少数据访问的复杂度。把对数据库的直接操作 , 转换为对持久对象的操作 .

Struts 、 spring 、 Hibernate 在各层的作用

1 ） struts 负责 web 层 .

ActionFormBean 接收网页中表单提交的数据，然后通过 Action 进行处理，再 Forward 到对应的网页。

在 struts-config.xml 中定义 <action-mapping>, ActionServlet 会加载。

2 ） spring 负责业务层管理，即 Service （或 Manager).

1 ． service 为 action 提供统计的调用接口，封装持久层的 DAO.

2 ．可以写一些自己的业务方法。

3 ．统一的 javabean 管理方法

4 ．声明式事务管理

5. 集成 Hiberante

3 ） Hiberante ，负责持久化层，完成数据库的 crud 操作

hibernate 为持久层，提供 OR/Mapping 。

它有一组 .hbm.xml 文件和 POJO, 是跟数据库中的表相对应的。然后定义 DAO ，这些是跟数据库打交道的类，它们会使用 PO 。

在 struts+spring+hibernate 的系统中，

对象的调用流程是： jsp-> Action － > Service ->DAO ->Hibernate 。

数据的流向是 ActionFormBean 接受用户的数据， Action 将数据从 ActionFromBean 中取出，封装成 VO 或 PO,

再调用业务层的 Bean 类，完成各种业务处理后再 forward 。而业务层 Bean 收到这个 PO 对象之后，会调用 DAO 接口方法，进行持久化操作。

控制反转(Ioc)
        控制反转（IOC）模式(又称DI：Dependency Injection)就是Inversion of Control，控制反转。在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。

        IoC(Inversion of Control)是近年来兴起的一种思想，不仅仅是编程思想。主要是协调各组件间相互的依赖关系，同时大大提高了组件的可移植性，组件的重用机会也变得更多。在传统的实现中，由程序内部代码来控制程序之间的关系。我们经常使用new关键字来实现两组键间关系的组合，这种实现的方式会造成组件之间耦合(一个好的设计，不但要实现代码重用，还要将组件间关系解耦)。IoC很好的解决了该问题，它将实现组件间关系从程序内部提到外部容器来管理。也就是说由容器在运行期将组件间的某种依赖关系动态的注入组件中。控制程序间关系的实现交给了外部的容器来完成。即常说的好莱坞原则“Don't call us, we'll call you”。

      Ioc也有称为DI(Dependecy Injection 依赖注射)，由Martin Fowler的一篇《Inversion of Control Containers and the Dependency Injection pattern》提出。

　　分离关注（ Separation of Concerns : SOC）是Ioc模式和AOP产生最原始动力，通过功能分解可得到关注点，这些关注可以是 组件Components, 方面Aspects或服务Services。

　　从GOF设计模式中，我们已经习惯一种思维编程方式：Interface Driven Design 接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：

　　AInterface a = new AInterfaceImp();

　　AInterfaceImp是接口AInterface的一个子类，Ioc模式可以延缓接口的实现，根据需要实现，有个比喻：接口如同空的模型套，在必要时，需要向模型套注射石膏，这样才能成为一个模型实体，因此，我们将人为控制接口的实现成为“注射”。

　　Ioc英文为 Inversion of Control，即反转模式，这里有著名的好莱坞理论：你呆着别动，到时我会找你。

　　其实Ioc模式也是解决调用者和被调用者之间的一种关系，上述AInterface实现语句表明当前是在调用被调用者AInterfaceImp，由于被调用者名称写入了调用者的代码中，这产生了一个接口实现的原罪：彼此联系，调用者和被调用者有紧密联系，在UML中是用依赖 Dependency 表示。

　　但是这种依赖在分离关注的思维下是不可忍耐的，必须切割，实现调用者和被调用者解耦，新的Ioc模式 Dependency Injection 模式由此产生了， Dependency Injection模式是依赖注射的意思，也就是将依赖先剥离，然后在适当时候再注射进入。

一、Ioc模式（Dependency Injection模式）有三种：

      第一种类型 从JNDI或ServiceManager等获得被调用者，这里类似ServiceLocator模式。 1.EJB/j2ee 2. Avalon（Apache的一个复杂使用不多的项目）
      第二种类型 使用JavaBeans的setter方法 1. Spring Framework,2.WebWork/XWork
      第三种类型 在构造方法中实现依赖 1. PicoContainer,2. HiveMind

　　有过EJB开发经验的人都知道，每个EJB的调用都需要通过JNDI寻找到工厂性质的Home接口，在我的教程EJB是什么章节中，我也是从依赖和工厂模式角度来阐述EJB的使用。

　　在通常传统情况下，为了实现调用者和被调用者解耦，分离，一般是通过工厂模式实现的，下面将通过比较工厂模式和Ioc模式不同，加深理解Ioc模式。

二、工厂模式和Ioc

　　假设有两个类B 和 C：B作为调用者，C是被调用者，在B代码中存在对C的调用：

java 代码
public class B{   
　　 private C comp;    
　　......   
}   

　　实现comp实例有两种途径：单态工厂模式和Ioc。

工厂模式实现如下：

java 代码
public class B{   
　　 private C comp;    
　　private final static MyFactory myFactory = MyFactory.getInstance();   
  
　　public B(){   
　　　　this.comp = myFactory.createInstanceOfC();   
  
　　}   
　　 public void someMethod(){   
　　　　this.comp.sayHello();   
　 }    
　　......   
}   

特点：

每次运行时，MyFactory可根据XML配置文件中定义的C子类实现，通过createInstanceOfC()生成C的具体实例。
使用Ioc依赖性注射( Dependency Injection )实现Picocontainer如下，B类如同通常POJO类，如下：

java 代码
public class B{   
　　 private C comp;    
　　public B(C comp){   
　　　　this.comp = comp;   
　　 }   
　　 public void someMethod(){   
　　　　this.comp.sayHello();   
　　 }   
　　......   
}   

假设C接口/类有有一个具体实现CImp类。当客户端调用B时，使用下列代码：

java 代码
public class client{   
　　 public static void main( String[] args ) {   
　　　　DefaultPicoContainer container = new DefaultPicoContainer();   
　　　　container.registerComponentImplementation(CImp.class);   
　　　　container.registerComponentImplementation(B.class);   
　　　　B b = (B) container.getComponentInstance(B.class);   
　　　　b.someMethod();   
　　 }   
}   

　　因此，当客户端调用B时，分别使用工厂模式和Ioc有不同的特点和区别：

　　主要区别体现在B类的代码，如果使用Ioc，在B类代码中将不需要嵌入任何工厂模式等的代码，因为这些工厂模式其实还是与C有些间接的联系，这样，使用Ioc彻底解耦了B和C之间的联系。

　　使用Ioc带来的代价是：需要在客户端或其它某处进行B和C之间联系的组装。

　　所以，Ioc并没有消除B和C之间这样的联系，只是转移了这种联系。
　　这种联系转移实际也是一种分离关注，它的影响巨大，它提供了AOP实现的可能。

Ioc和AOP
　　AOP我们已经知道是一种面向切面的编程方式，由于Ioc解放自由了B类，而且可以向B类实现注射C类具体实现，如果把B类想像成运行时的横向动作，无疑注入C类子类就是AOP中的一种Advice，如下图：

　　通过下列代码说明如何使用Picocontainer实现AOP，该例程主要实现是记录logger功能，通过Picocontainer可以使用简单一行，使所有的应用类的记录功能激活。

首先编制一个记录接口：

java 代码
public interface Logging {   
  
　　public void enableLogging(Log log);   
  
}  

有一个LogSwitcher类，主要用来激活具体应用中的记录功能：

java 代码
import org.apache.commons.logging.Log;   
public class LogSwitcher   
{   
　 protected Log m_log;   
　 public void enableLogging(Log log) {   
　　　　m_log = log;   
　　　　m_log.info("Logging Enabled");   
　　}   
}   

一般的普通应用JavaBeans都可以继承这个类，假设PicoUserManager是一个用户管理类，代码如下：

java 代码
public class PicoUserManager extends LogSwitcher   
{    
　　..... //用户管理功能   
}   
public class PicoXXXX1Manager extends LogSwitcher   
{    
  
　　..... //业务功能   
}   
public class PicoXXXX2Manager extends LogSwitcher   
{    
  
　　..... //业务功能   
}  

注意LogSwitcher中Log实例是由外界赋予的，也就是说即将被外界注射进入，下面看看使用Picocontainer是如何注射Log的具体实例的。

java 代码
DefaultPicoContainer container = new DefaultPicoContainer();   
container.registerComponentImplementation(PicoUserManager.class);   
container.registerComponentImplementation(PicoXXXX1Manager.class);    
container.registerComponentImplementation(PicoXXXX2Manager.class);   
.....    
  
Logging logging = (Logging) container.getComponentMulticaster();   
  
logging.enableLogging(new SimpleLog("pico"));//激活log  

　　由上代码可见，通过使用简单一行logging.enableLogging()方法使所有的应用类的记录功能激活。这是不是类似AOP的advice实现？

　　总之，使用Ioc模式，可以不管将来具体实现，完全在一个抽象层次进行描述和技术架构，因此，Ioc模式可以为容器、框架之类的软件实现提供了具体的实现手段，属于架构技术中一种重要的模式应用。J道的JdonSD框架也使用了Ioc模式。

参考资料：

Inversion of Control Containers and the Dependency Injection pattern
A Brief Introduction to IoC
Ioc容器的革命性优点
Java企业系统架构选择考量
IOC模式的思考和疑问

三、IoC的几种实现类型

(1)Type1接口注入

通常做法是利用接口将调用者与实现者分离。

java 代码
public class Sport {   
private InterfaceBall ball; //InterfaceBall是定义的接口   
public void init() {   
//Basketball实现了InterfaceBall接口   
ball = (InterfaceBall) Class.forName("Basketball").newInstance();   
}   
}  

Sport类在编译期依赖于InterfaceBall的实现，为了将调用者与实现者分离，我们动态生成Basketball类并通了强制类型转换为InterfaceBall。Apache Avalon是一个典型的Type1型IoC容器。

(2)setter方法注入

在类中暴露setter方法来实现依赖关系。

java 代码
public class Sport {   
private InterfaceBall ball;   
public void setBall(InterfaceBall arg) {   
ball = arg;   
}   
}  

这种方式对已经习惯了JavaBean的程序员而言，更显直观。Spring就是实现了该类型的轻量级容器。

(3)Type3构造子注入

即通过构造方法完成依赖关系。

java 代码
public class Sport {   
private InterfaceBall ball;   
public Sport(InterfaceBall arg) {   
ball = arg;   
}   
}  

可以看到，通过类的构造方法建立依赖关系。由于Type3在构造期就形成了对象的依赖关系，即存对象的重用变的困难。有些框架需要组件提供一个默认的构造方法，此时就体现了Type3的局限性。通常所有的参数都是通过构造方法注入的，当对象间的依赖关系较多时，构造方法就显的比较复杂，不利于单元测试。PicoContainer就是实现了Type3依赖注入模式的轻量级容器。