JAVA SSH开发架构中Action层,Service层,modle层,Dao层的功能区分

首先这是现在最基本的分层方式，结合了SSH架构。modle层就是对应的数据库表的实体类。Dao层是使用了Hibernate连接数据库、操作数据库（增删改查）。Service层：引用对应的Dao数据库操作，在这里可以编写自己需要的代码（比如简单的判断）。Action层：引用对应的Service层，在这里结合Struts的配置文件，跳转到指定的页面，当然也能接受页面传递的请求数据，也可以做些计算处理。以上的Hibernate，Struts，都需要注入到Spring的配置文件中，Spring把这些联系起来，成为一个整体。

一般java都是三层架构 数据访问层（dao） 业务逻辑层（biz 或者services） 界面层（ui）
action 是业务层的一部分，是一个管理器 （总开关）（作用是取掉转）（取出前台界面的数据，调用biz方法，转发到下一个action或者页面）
模型成（model）一般是实体对象(把现实的的事物变成java中的对象)作用是一暂时存储数据方便持久化（存入数据库或者写入文件）而是 作为一个包裹封装一些数据来在不同的层以及各种java对象中使用
dao是数据访问层 就是用来访问数据库实现数据的持久化（把内存中的数据永久保存到硬盘中）

 

Dao主要做数据库的交互工作
Modle 是模型 存放你的实体类
Service 做相应的业务逻辑处理
Action是一个控制器

Struts+Spring+Hibernate (一下简称为SSH)，SSH架构是当前非常火的架构，很多金融、电信项目，大型门户网站均选择该架构作为业务支撑架构，开发流程也已经非常成熟。但是该结构开发起来，依旧存在一些问题。分析这些问题，得先从SSH架构的组成说起。

    SSH为Struts+Spring+Hibernate的组成方式，Struts实现MVC，Spring负责架构的结合，Hibernate进行数据的持久化。通常其分层开发的结构图(以一个业务新增为例)如下：

这样的结构，满足了一般的业务需要，但是对于当前日益复杂化的WEB2.0的开发，却存在不少问题，归纳起来主要有以下几点的不足：

 

    A)DAO和服务层容易出现职责不明，由于按照MVC逻辑，业务代码应该写在Struts Action里，但是其事务的提供，却是配置在Service层。为了一组在逻辑上完整的数据操作业务逻辑，需要涉及两个层（Serveice、Action）来进行编写，遇到判断的情况下，为了保证完整的事务操作，则需要将业务代码移到Service层完成，而通常习惯了在Struts Action里调用多次Service而产生多个事务而在出现Exception时导致出错时操作之前调用的Service事务的业务数据没有回滚。

 

    B)当需要返回的数据供AJAX使用，操作JSON或XML的的大量使用时。开发起来会很费力，一段同样的业务代码，为了使用AJAX和XML可能需要重新编写一次，或者在同一个ACTION里通过标志来判断，对分层结构造成了比较糟糕的破坏。如果设计得不好，为了使用JSON和XML还得额外增加大量的配置，严重降低了开发效率。

 

    因此，为了克服这些缺点，本人对于SSH架构，进行了实现了重新的分层，共享了业务代码。简化了开发、增强了与AJAX技术、MXL技术的结合。提供了一种更高效的开发模式。

 

其开发的结构图如下：

 

    看到这个架构图有人可能会问，Struts Action类的编写去哪了呢？答案正是这个架构的优点，由于业务代码统一实现IbusinessService接口，使得只需要相对固定的几个Struts Action类调用Service层的方法，便可以完成工作。包括JSON格式输出，XML输出及WebService输出均调用Service层方法来完成功能。这样便实现了业务代码的分离，以及与前端框架的极大解耦。