一、SSH架构最基本的分层方式：
modle层：就是对应的数据库表的实体类，即将现实对象抽象成类。
Dao层：是使用了Hibernate连接数据库、操作数据库（增删改查）和model层。
Service层：引用对应的Dao数据库操作，在这里可以编写自己需要的代码（比如简单的判断）。
Action层：引用对应的Service层，在这里结合Struts的配置文件，跳转到指定的页面，当然也能接受页面传递的请求数据，也可以做些计算处理。
以上的Hibernate，Struts，都需要注入到Spring的配置文件中，Spring把这些联系起来，成为一个整体。
一般java都是三层架构：数据访问层（dao）、 业务逻辑层（biz 或者services）、 界面层（ui）
action 是业务层的一部分，是一个管理器（总开关）（作用是取调转）（取出前台界面的数据，调用service方法，转发到下一个action或者页面） model模型层：一般是实体对象(把现实的的事物变成java中的对象)作用是一暂时存储数据方便持久化（存入数据库或者写入文件）二是作为类封装一些数据来在不同的层以及各种java对象中使用。
dao是数据访问层 就是用来访问数据库实现数据的持久化（把内存中的数据永久保存到硬盘中）
Modle 是模型，存放你的实体类
Dao主要做数据库的交互工作（hibernate）
Service 做相应的业务逻辑处理
Action是一个控制器（structs）
java中dao层和service层的区别是什么？
service是业务层，dao是数据访问层。
这个问题我曾经也有过，记得以前刚学编程的时候，都是在service里直接调用dao，service里面就new一个dao类对象，调用，其他有意义的事没做，也不明白有这个有什么用，参加工作久了以后就会知道，业务才是工作中的重中之重。
我们都知道，标准主流现在的编程方式都是采用MVC综合设计模式，MVC本身不属于设计模式的一种，它描述的是一种结构，最终目的达到解耦，解耦说的意思是你更改某一层代码，不会影响我其他层代码，
如果你会像spring这样的框架，你会了解面向接口编程，表示层调用控制层，控制层调用业务层，业务层调用数据访问层。
初期也许都是new对象去调用下一层，比如你在业务层new一个DAO类的对象，调用DAO类方法访问数据库，这样写是不对的，
因为在业务层中是不应该含有具体对象，最多只能有引用，如果有具体对象存在，就耦合了。当那个对象不存在，我还要修改业务的代码，这不符合逻辑。好比主板上内存坏了，我换内存，没必要连主板一起换。我不用知道内存是哪家生产，不用知道多大容量，只要是内存都可以插上这个接口使用。这就是MVC的意义。
在各层中不要含有其他层的new的具体对象，最多只能有引用。
接下来说你感觉service的意义，其实因为你现在做东西分层次不是那么严格，在一个你们做东西业务本身也少，举个最简单的例子，你做一个分页的功能，数据1000条，你20条在一个页，你可以把这个功能写成工具类封装起来，然后在业务层里调用这个封装的方法，这才是业务里真正干得事，只要没访问数据库的，都要在业务里写。
只是刚开始写的代码都是有个请求，就去数据库取，业务几乎没有，这是不对的。
二、Action层, Service层 ，modle层 和 Dao层的功能区分
Action主要的功能就是组织service的，比如你要做权限验证，那么请求会被Action获取，那么如何验证呢？Action可不管他要问service该怎么办。当得到service返回的结果后根据结果判断下一跳是哪里（如果验证用户存在且密码正确则跳转到登录成功的页面，反之则回跳到登录页面）
现在轮到service了，service是管理业务的，延续上面的例子的话，action问这个用户是否合法有效的时候sevice就去调用dao层，看dao能不能找到相应的记录，当业务受到dao的结果后就根据得到的记录回答action的问题“用户是否合法有效”
最后就是dao了，作为工作于最“基层”的部分，dao层只去实现增删查改，甚至这些增删查改之间有什么关系？dao一概不问，爱谁是谁。dao很倔强，它只保证和数据库的关系良好。
归纳一下，Action就是管理业务（servcie）调度和管理跳转的。service是管理具体的功能的，这个很容易和Action混淆，你可以这样理解，Action只负责管理，而service负责实施，dao只完成增删查改，当然你可以1-n，n-n，1-1关联，模糊 、动态 、子查询都可以。但是无论多么复杂的dao，它只是封装增删查改。至于增删查改如何实现一个功能，dao层是不管的。
总结这三者，可以举个例子，action像是服务员，顾客点什么菜，菜上给几号桌，都是action的职责；sevice是厨师，action送来的菜单上的菜全是service做的；dao是厨房的小工，和原材料打交道的事情全是它管。所以小工（dao）的工作是要满足厨师（service）的要求，厨师要满足服务员（action）转达的客户（页面用户）的要求，服务员自然就是为客户服务喽。
首先这是现在SSH架构最基本的分层方式。modle层就是对应的数据库表的实体类。Dao层是使用了Hibernate连接数据库、操作数据库（增删改查）。Service层：引用对应的Dao数据库操作，在这里可以编写自己需要的代码（比如简单的判断）。Action层：引用对应的Service层，在这里结合Struts的配置文件，跳转到指定的页面，当然也能接受页面传递的请求数据，也可以做些计算处理。以上的Hibernate，Struts，都需要注入到Spring的配置文件中，Spring把这些联系起来，成为一个整体。
简单的说：
struts 控制用的
hibernate 操作数据库的
spring 用解耦的
详细的说：
STRUTS 在 SSH 框架中起控制的作用 , 其核心是 Controller, 即 ActionServlet, 而 ActionServlet 的核心就是 Struts-confi g.xml. 主要控制逻辑关系的处理 .
hibernate 是数据持久化层 , 是一种新的对象、关系的映射工具 , 提供了从 Java 类到数据表的映射，也提供了数据查询和恢复等机制 , 大大减少数据访问的复杂度。把对数据库的直接操作 , 转换为对持久对象的操作 .
SPRING 是一个轻量级的控制反转 (IoC) 和面向切面 (AOP) 的容器框架 , 面向接口的编程 , 由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控。这也就是所谓 “ 控制反转 ” 的概念所在：（依赖）控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中起到的主要作用是解耦
Struts 、 spring 、 Hibernate 在各层的作用
1 ） struts 负责 web 层 .
ActionFormBean 接收网页中表单提交的数据，然后通过 Action 进行处理，再 Forward 到对应的网页。
在 struts-config.xml 中定义
2 ） spring 负责业务层管理，即 Service （或 Manager).
1 ． service 为 action 提供统计的调用接口，封装持久层的 DAO.
2 ．可以写一些自己的业务方法。
3 ．统一的 javabean 管理方法
4 ．声明式事务管理
- 集成 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 接口方法，进行持久化操作。
SSH框架都是取其优点的：
Hibernian 的最大好处就是根据数据库的表反向生成实体类，并且还有关系在里面，还有就是它的对数据的操作也很方便。
Spring 我理解的就是创建对象工厂，省去了在类里面new 对象的过程，把这个调用与被调用的关系直接展示到了配置文件里，做任何操作都变简单了。
项目实现举例
程序框架搭好，各种jar包导好后，开工了
就拿注册功能来说 页面只有两个文本框 一个用户名（uname） 一个密码(pwd)
首先是action层： 它是负责在页面和程序之间传输数据的，还有作用是做页面跳转。页面由用户填写表单数据，点击提交按钮，页面的表单数据由Hibernian自动封装到该页面表单所对应的ActionFrom（ActionFrom跟实体类不是一个东西，ActionFrom是页面有什么值，我类里就写什么属性，是封装表单数据用的。而实体类是完全按照数据库的字段生成的，实体类可以当做ActionFrom用，但ActionFrom绝对不可以当做实体类用），这样表单数据就以ActionFrom对象的形式在Action的点击提交按钮执行的那个方法里存在了，这个时候你需要的就是把表单数据存入数据库中，但如果数据库里并非只有页面上的uname和pwd两个字段，还有其他字段比如用户状态，那你就需要另行在程序里给该属性赋值了，否则会报非空错误，这里的例子，页面只有两个文本框，数据库也只有这两个字段，就不必考虑那么多了，到这一步，action的功能告一段落了，接着是把数据传入services层。
Biz层（业务逻辑层）/service层：
它负责的是对数据的处理，比如网站功能是点卡销售，你就需要在这个层里对点卡的打折啊其他的数学问题做操作了，在这个例子里，此层只做单纯的数据传递作用，而后又到了DAO层。
Dao层（数据库操作层）：它负责对数据向数据库增删改查的操作。
以上例子，不使用spring的话，每个层之间的数据传递你都需要new一个调用该层数据的类的实例，而使用了spring的话，你需要做的就是把Dao 层和services层的每个类都写一个接口类，接口类里写实现类的方法，在调用的时候不new 对象，直接用对象点(.)方法就可以，别忘了对每个对象加set/get方法。
业务逻辑层）/service层例子：
private saveMyScheduleDaoImpl smsDI; //类里定义写接口(saveMyScheduleDaoImpl )，不要写实现类，并且不new
set/get方法略·········
public List saveMySchedule(Schedule s)
{
return smsDI.saveMySchedule(s); //因为是接口的实例，所以要求该接口里必须写上实现类的所有方法，这样才能点（.）
}
这里只简单写了一个services层的。
以上流程只是从页面获取值存入数据库，是单向的Action层->services层->Dao层的数据传递，Dao层->services层->Action层的数据传递和我刚刚将的一样，就是反过来了。
到这一步的总结：
Dao层写接口并且接口里写实现类的所有方法。
Services层写接口并且接口里写实现类的所有方法。调用Dao层方法只定义Dao层需要调用方法所属的类的接口，而后添加get/set方法，再用该接口的没有new的实例点（.）方法。
Action层同Biz层。
下面就是强大的spring的工作了-------依赖注入
所有改写的死东西都写完了，我们就差在配置文件里依赖注入了
找到spring的配置文件，先注Dao层，这个时候一定要注意一点，就是依赖注入的时候注的必须是实体类！！ 而不是接口！！ 这是一种良好的变成习惯。
Dao层的依赖注入里绑定的是你在往工程加Spring的时候让你填写SessionFactory的那个值，配置文件上面应该会有这个bean的。
然后是Services层的依赖注入，同样也是注实体类，根据我这个例子里面会有smsDI需要绑定，这个时候填写你注的Dao层的相对应的类的名字就行。
然后是Action层的依赖注入，大体同Services层一样。
依赖注入完毕后，你就可以配置了。
原文链接：https://blog.csdn.net/david_snjly/java/article/details/45568573