SSH开发新方案之基于SSH开发架构的重新分层.docxVIP

SSH开发新方案之基于SSH开发架构的重新分层?现代的企业开发中，越来越多地引入了多层架构设计模式。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层方法来完成功能。这样便实现了业务代码的分离，以及与前端框架的极大解耦。结合spring+hibernate与jdbc的事务问题背景：我们是一家工作流公司，客户采购我们的产品后，将其嵌入其项目中。我们的工作流采用的是?? spring+hibernate的方式，客户项目则是jdbc直接进行数据库操作。问题：客户在其数据库操作过程中需要调用我们的工作流接口，这样就需要将我们的工作流操作与他们的业? 务操作置于同一个事务中。我们的服务采用的都是spring的声明式事务，而客户采用的是对???????? connection进行事务处理。如何保证事务的一致性？想到的解决方案一：使用jta事务，用tomcat+jotm提供事务管理器。为什么一开始就想到要使用jta事务？？实际上我们和客户都是使用的同一个数据库，为了方便，各自使用了不同的数据库连接方式，使用jta的话确实有bt的意思在里面。但是事实上是我们的第一反应都是jta。最后没有采用该方法的原因也很简单：我没有将jotm配置成功！汗一个。想到的解决方案二：将客户的这些特定代码用spring管理起来。因为要修改客户部分代码，这个方案遭到了客户的强烈反对。于是放弃。想到的解决方案三：客户数据库操作与我们的服务使用同一个数据库连接。然后编程处理事务。存在两种方式：一种是把客户的连接传给我们，另一种则是把我们的连接传给客户。第一种方式对我们的影响太大，所以最后决定采用后一种方式：从hibernate session中获取connection然后传递给客户。接下来查看一下HibernateTemplate的execute()方法，思路就很简单了：获取定义的sessionFactory--创建一个新的session并打开--将session与当前线程绑定--给客户代码返回connection--打开事务--客户使用我们传递的connection进行数据库操作--我们不带声明事务的服务操作--提交事务--解除绑定。实际要注意的地方是：1、将session与当前线程绑定使用的TransactionSynchronizationManager.bindResource()方法，这样在HibernateTemplate里才能找到session；??????????????????? 2、我们的服务一定要把声