金立手机外勤系统架构设计文档.docx

金立手机外勤系统架构设计文档.docx

《金立手机外勤系统架构设计文档.docx》由会员分享，可在线阅读，更多相关《金立手机外勤系统架构设计文档.docx（12页珍藏版）》请在冰豆网上搜索。

金立手机外勤系统架构设计文档

金立手机外勤系统架构设计说明书

2012年8月

1.目的

本说明书的编写目的是为了描述系统的架构设计方案，该方案是详细设计的依据。

2.系统架构设计

整个软件架构方案采用分层结构，明确地分离了表现层和业务逻辑，能够保证应用服务逻辑的一致性和稳定性、结构的开放性、功能的可扩展性和可维护性、开发的可并行性，同时采用一些开源的框架，兼顾了经济性。

框架是一种特殊的软件，它为软件开发带来了高度的重用性，是无数软件开发人员的多年项目开发经验的总结。

在一个优秀的框架上开发应用，而不是从零开始，可以大量缩短项目的开发周期、降低开发风险、增强应用系统的稳定性。

从架构图中可以看出系统分为三层：

·表示层：

借助Struts及Ext实现

·业务层：

借助Spring进行业务组件的组装关联。

·数据持久层：

借助Hibernate实现

通过成熟的开源产品实现各层，同自己编写代码实现，相比之下能缩短开发周期，且架构所用到的开源产品均有很广泛的用户群，经受过实践的考验，质量和性能更有保障。

·层与层之间松散耦合，增加代码重用率。

·各层分工明确，这样也利于团队的明确分工。

系统的总体架构从结构上分为表示层、业务层、数据访问层以及在层间传递数据的数据传输对象。

下面针对各层加以描述。

1）表示层

表示层与客户端对应，采用浏览器与用户交互，把来自系统的信息显示给用户，主要控制页面外观，产生页面逻辑以及对用户输入的数据进行合法性验证。

系统中主要包括基于EXT框架的JavaScript脚本及基于Struts框架的JSP、Action。

2）业务层

业务层处理应用的核心业务逻辑。

业务逻辑对象BLO（BusinessLogicObject）把业务规则、约束、活动和数据结合在一起，Spring负责对这些业务对象的管理。

3）数据访问层

数据访问对象（DataAccessObject）把底层的数据访问操作和上层的商务逻辑分开。

4）数据传输对象（DataTransferObject）

数据传输对象通常作为各业务实体的JAVABEAN对象，负责层与层之间数据的传输。

5）手机交互

通过ApacheCXF向外提供访问接口，并将这些接口交给spring进行管理。

提供3种格式的数据交互，json，xml，atom-xml。

6）中间件

通过ralasafe进行权限管理，ireport制作报表。

3系统模块设计

系统组件图

4.架构总体功能概要设计

4.1Struts框架

Struts是一个实现了MVC模式的框架，对Model、View和Controller都提供了对应的实现组件，可分为1.x和2.x两大版本。

1.控制器的作用是从客户端接受请求，并且选择执行相应的业务逻辑，然后把响应结果送回到客户端。

在Struts1中Controller功能由图中ActionServlet和ActionMapping对象构成：

核心是一个Servlet类型的对象ActionServlet，它用来接受客户端的请求。

ActionServlet包括一组基于配置的ActionMapping对象，每个ActionMapping对象实现了一个请求到一个具体的Action处理器对象之间的映射；在Struts2中Controller为基于事务拦截的拦截器，针对每次客户端请求Action进行拦截分发。

2．模型（Model）

MVC系统中的Model部分从概念上可以分为两类--系统的内部状态，和改变系统状态的动作。

Struts1为Model部分提供了Action和ActionForm对象：

所有的Action处理器对象都是开发者从Struts的Action类派生的子类。

Action处理器对象封装了具体的Struts配置文件、Controller、Model、Action、View、JSP处理逻辑，调用业务逻辑模块，并且把响应提交到合适的View组件以产生响应。

Struts提供的ActionForm组件对象，它可以通过定义属性描述客户端表单数据。

开发者可以从它派生子类对象，利用它并结合Struts提供的自定义标记库，可以实现对客户端的表单数据的良好封装和支持，Action处理器对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。

通过ActionForm组件对象实现了对View和Model之间交互的支持；Struts2的Action为ActionSupport基类的子类，由于对于每一个Action请求生成一个实例对象，不存在线程安全问题。

3．视图（View）

Struts应用中的View部分是通过JSP技术实现的。

Struts提供了自定义的标记库可以使用，通过这些自定义标记可以很好地和系统的Model部分交互，通过使用这些自定义标记创建的JSP表单，可以实现和Model部分中的ActionForm的映射，完成对用户数据的封装，同时这些自定义标记还提供了像模板定制等多种显示功能。

4.2Spring框架

Spring是一个轻量级的实现了控制反转（IoC）和面向切面（AOP）的容器框架，其组件包括：

1．Core包Core包是框架的最基础部分，它提供依赖注入（DependencyInjection）特性来管理Bean容器功能。

2．Context包Context包提供了框架的资源访问方式，如JNDI、资源装载等的接口。

3．DAO包DAO包提供了JDBC的抽象层，它可消除冗长的JDBC编码和解析数据库厂商的特有代码。

该包也提供了实现编程性和声明性事务管理的方法。

4．ORM包ORM包为流行的关系－对象映射APIs提供了集成层，包括JDO，Hibernate和iBatis。

5．AOP包AOP包提供与AOP联盟兼容的面向方面编程实现，允许用户定义，如方法拦截器和切点，来从逻辑上把应该被分离的功能实现代码解耦。

6．Web包Web包提供了基本的面向Web的特性。

如MVC以及与其他Web框架的结合。

Spring提供了一致的事务管理抽象。

这个抽象是Spring最重要的抽象之一，它有如下的优点：

·为不同的事务API提供一致的编程模型，如JTA、JDBC、Hibernate、iBatis数据库层和JDO。

·提供比大多数事务API更简单的，易于使用的编程式事务管理API。

·整合Spring数据访问抽象。

·支持Spring声明式事务管理。

Spring使应用开发者能够使用在任何环境下使用一致的编程模型，只写一次代码，就可以实现不同环境下的事务管理。

Spring同时提供声明式和编程式事务管理。

其中声明式事务管理仅通过一些配置就使得事务管理从业务逻辑分离出来，极大地减轻了开发人员的负担。

4.3Hibernate框架

Hibernate是一个实现了以ORM模式实现了持久层的框架，由于数据库的读写是一个很耗费时间和资源的操作，当大量用户同时直接访问数据库的时候，效率将非常低，如果将数据持久化就不需要每次从数据库读取数据，直接在内存中对数据进行操作，这样就节约了数据库资源，而且加快了系统的反映速度。

Hibernate提供的接口可以分为以下几类：

（1）提供访问数据库的操作的接口，包括session、Transaction、Query接口；

（2）用于配置Hibernate的接口，Configuration；

（3）间接接口，使应用程序接受Hibernate内部发生的事件，并作出相关的回应，包括：

Interceptor、Lifecycle、Validatable；

（4）用于扩展Hibernate功能的接口，如UserType、CompositeUserType、IdentifierGenerator接口。

Hibernate内部还封装了JDBC、JTA（JavaTransactionAPI）和JNDI（JavaNamingAndDirectoryInterface）。

其中，JDBC提供底层的数据访问操作，只要用户提供了相应的JDBC驱动程序，Hibernate可以访问任何一个数据库系统。

JTA和JNDI使Hibernate能够和J2EE应用服务器集成。

4.4ExtJS框架

ExtJS是一个JavaScript框架，包括丰富的JS函数库，用于在客户端创建丰富多彩的Web应用程序界面，增强用户体验及界面友好性。

ExtJS由一系列的类库组成，包括如下几个部分：

底层API（core）：

底层API中提供了对DOM操作、查询的封装、事件处理等基础功能，其他控件也是建立在这些底层API的基础上的。

控件（widgets）：

控件是指可以直接在页面创建的可视化组件，如面板、选项板、表格、树、窗口、菜单、工具栏、按钮等，在系统中可以直接通过应用这些控件来增强界面的友好及交互性。

实用工具（utils）：

Ext提供了很多实用的工具，通过它们可以实现数据内容格式化、JSON数据解析、AJAX调用、Cookie管理、CSS管理等功能。

同时，Ext也是一个Ajax框架，提供了一套通过AJAX方式与服务器异步交互的机制，即不通过页面刷新就可以访问服务器的程序进行数据读取与保存。

ExtJS与服务器端的数据交互可以通过XML或JSON对象格式。

由于JSON对象格式比XML格式更易于解析和理解，本系统前端与服务器端进行数据交互的方式采用JSON对象。

4.5缓存机制

缓存是介于应用程序和物理数据源之间的数据内存，其作用是为了降低应用程序对物理数据源访问的频次，从而提高了应用的运行性能。

缓存内的数据是对物理数据源中的数据的复制，应用程序在运行时从缓存读写数据，在特定的时刻或事件会同步缓存和物理数据源的数据。

Hibernate提供了两级缓存架构，第一级缓存是Session缓存；该级缓存缺省被Hibernate启用，并且是基于事务级别的缓存。

第二级缓存是SessionFactory缓存，该级缓存对Hibernate来说是可选的且可通过缓存插件来进行配置，并且是基于应用级别的缓存，也就是说它被该应用范围内的所有事务所共享。

由于Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。

为此，Hibernate提供了针对条件查询的Query缓存，该缓存可以把某个或多个Query查询放入到二级缓存中。

当然，二级缓存的使用也需要一些前提条件，并且带来了一些限制。

首先要求Hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，Hibernate是不可能知道的。

所有操作数据库必需直接通过Hibernate，如果调用存储过程，或者使用JDBC更新数据库，Hibernate也是不知道的，Hibernate的大批量更新和删除是不更新二级缓存的，这样就限制了大批量更新和删除的数据的使用。

针对该系统前期系统用户量不大、并发要求不高的情况，只采用一级缓存。

4.6数据批量处理

数据批量处理是指在一个事务中处理大量数据，一般说来，应该尽可能避免在应用程序中进行批量操作，而应该在数据库中直接进行批量操作，但同时带来了数据库的可移植性差，所以针对小批量的数据更新（100条以内），可以在应用层进行批量操作，操作方式主要有：

（1）通过Session来进行批量操作。

（2）通过StatelessSession来进行批量操作。

（3）通过HQL来进行批量操作。

（4）直接通过JDBCAPI来进行批量操作。

为了开发方便，我们选用Session来进行批量操作，Session的save（）以及update（）方法都会把处理的对象存放在自己的缓存中。

如果通过一个Session对象来处理大量持久化对象，应该及时从缓存中清空已经处理完毕并且不会再访问的对象。

具体的做法是在处理完一个对象或小批量对象后，立刻调用flush（）方法清理缓存，然后再调用clear（）方法清空缓存。

并且需进行如下设置：

（1）需要在Hibernate的配置文件中设置JDBC单次批量处理的数目，合理的取值通常为10到50之间，本系统采用hibernate.jdbc.batch_size=20，并应保证每次向数据库发送的批量SQL语句数目与这个batch_size属性一致。

（2）如果对象采用"identity"标识符生成器，则Hibernate无法在JDBC层进行批量插入操作。

（3）批量操作时关闭二级缓存。

4.7加锁机制

加锁对于数据库来说是保障并发和数据一致性的重要手段，Hibernate作为对数据库实现持久化的一个框架，同样也有自己的加锁机制，Hibernate的加锁机制有悲观锁和乐观锁两种机制。

悲观锁（PessimisticLocking）假定任何时刻存取数据时，都可能有另一个事务也正在存取同一笔数据，为了保持数据被操作的一致性，于是对数据采取了锁定状态，Hibernate的加锁依靠数据库提供的锁机制来实现；乐观锁（OptimisticLocking）认为数据库的存取很少发生同时存取的问题，因而不对数据锁定。

为了维护正确的数据，乐观锁是使用应用程序上的逻辑来实现版本控制的。

Hibernate中通过检查版本号来判断数据是否已经被其他人所改动，在数据库中加入一个version字段记录，在读取数据时连同版本号一同读取，并在更新数据时比较版本号与数据库中的版本号，如果等于数据库中的版本号则予以更新，并递增版本号，如果小于数据库中的版本号就抛出异常。

悲观锁从根本上保证了数据的一致性，但因为等待解锁带来了性能及数据库表死锁的问题；针对本系统数据库表的更新操作并发量不大的特点，适合采取悲观锁，并采取防死锁机制。

4.8防死锁机制

在数据库系统中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死锁等待。

防止死锁的发生其实就是要破坏产生死锁的条件。

预防死锁通常有两种方法。

预防死锁通常有两种方法：

一次封锁法，一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。

一次封锁法虽然可以有效地防止死锁的发生，但由于扩大了加锁的范围，降低了系统的并发度；顺序封锁法，顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序执行封锁。

在本系统中将定义一个数据库表的访问顺序，并要求所有的事务都按照这个顺序访问操作数据库。

4.9表单验证

对Web应用来说，由于用户的行为是无法预测的，在表单数据在传递给业务类之前，必须保证数据的合法性及有效性，而表单验证是保证数据合法性及有效性的重要手段。

对于基于SSH框架的表单验证一般有两种方式：

基于JavaScript的表单验证（前端验证）及基于Struts的表单验证（后端验证）。

前端验证：

可以针对基本类型（汉字、英文、整型、数字、日期、邮编）的有效性及合法性开发出一些共同JavaScript函数，以备整个系统统一调用。

后端验证：

主要采用基于Struts的表单验证，通过ActionForm的validate函数进行验证。

由于前端验证不需要提交服务器，直接在客户端完成，从而减少了服务器的压力，所以我们优先采用前端验证。

4.10异常处理

异常处理的目的是为了让用户看到异常的详细信息，定位异常发生的原因，让开发人员对预期的异常进行处理，进一步提高系统的健壮性。

Java语言拥有一套自己的异常处理机制，在Java的异常体系结构中，异常被分为两类：

一类是基于java.lang.Exception的异常，被称为检查异常，这类异常必须在程序中予以扑获；另一类是基于java.lang.RuntimeException的异常，被称为运行异常，这类异常不必在程序中扑捉，而且用户对这类异常一般无法恢复，但通过业务处逻辑的判断理可以让程序避免这类异常的出现。

针对J2EE应用的多层架构，数据访问层和业务层可以根据需要向上层抛出相应的Exception，而这些Exception须在Action类中捕捉，并向页面返回一个合适的信息，具体展现根据情况来定，针对普通页面的异常，一般显示错误页面；Ajax发生的异常，返回一个包含错误信息的JSON对象，以Ajax方式显示。

系统首先定义一个异常基类BaseException，然后扩展定义BaseDAOException作为数据访问层的异常，扩展定义BaseBusinessException作为业务访问层的异常，而Action层的异常不做处理，通过Struts框架统一处理，并把表示层的异常统一转向异常页面，并提示异常信息。

系统都需要用日志文件来记录系统的运行，以便于跟踪和记录系统的运行情况。

系统发生的异常理所当然的需要记录在日志系统中，并且仅在最初产生异常的位置记录，在以后抛出并捕获该异常的位置则不再记录。

4.11日志处理

规范合理的日志记录能让开发人员和维护人员事半功倍，在记录日志时还应该考虑不同的角色对日志内容可能会有不同的需求。

比如，软件正常情况下提供给用户的日志应该简洁明了，调试时提供给程序员的日志应该详细明确。

LOG4J作为一个开源的日志管理组件，提供了强大的日志管理功能，可以把日志输出到控制台、文件或其他地方，支持包括Fatal、Error、Warn、Info、Debug多级日志输入。

并可以通过配置来控制日志的格式、输出级别。

本系统要求在每个函数的开始、结束位置、异常的初次抛出位置均要求输出到日志记录文件，并把用户的系统操作记录存入到数据库日志表。