基于JSF Spring Hibernate框架的web系统开发平台研究.docx

基于JSF Spring Hibernate框架的web系统开发平台研究.docx

《基于JSF Spring Hibernate框架的web系统开发平台研究.docx》由会员分享，可在线阅读，更多相关《基于JSF Spring Hibernate框架的web系统开发平台研究.docx（18页珍藏版）》请在冰豆网上搜索。

基于JSFSpringHibernate框架的web系统开发平台研究

基于JSF,Spring,Hibernate框架的web系统开发平台研究

摘要

开发web应用系统需要解决很多复杂问题，因此我们需要借助于第三方的开发平台，比如JavaEE，来降低开发成本。

遵循JavaEE规范的JavaEE框架，为一些web应用中的常见的问题提供了解决方案，可以使web应用开发变得简单高效。

目前各种JavaEE框架数目繁多，每一种框架都有其特定的应用范围，没有一种框架能够解决web应用中的所有问题，因此我们必须选择合适的框架整合起来组成一个系统开发的基础开发平台。

现在各种开源的JavaEE框架不断涌现，JavaEE官方框架也不断推陈出新，为我们提供了很多选择。

通过比较分析，本文选择新兴的JavaEE标准框架JSF和开源框架Spring,Hibernate作为web应用开发的解决方案。

本文首先在分析JavaEE规范多层结构的基础之上，确定了平台架构分层;其次对平台架构各主要层次进行分析，分析了web层、业务逻辑层所需采用的设计模式，对持久层的各种解决方案和DAO设计模式进行了分析;然后通过对比分析各种优秀的JavaEE开源框架以及标准框架来选择平台架构各个层次所用的框架，经过比较选择了JSF,Spring,Hibernate，给出了使用所选框架的平台架构，并对Spring和JSF,Hibernate的整合方法进行了分析，对JSF,Spring,Hibernate整合方案和其它整合方案进行了比较分析。

最后在开发平台的基础上通过一个旅行社电子商务系统的分析、设计、实现来验证开发平台的有效性，首先在系统功能描述的基础上，通过UML用例图和活动图对系统进行分析;其次划分系统功能模块、确定系统体系结构和运行环境;再次进行数据库设计、类设计、页面设计，在持久层设计了LineOrder等持久化类、以及与之协作的LineOrderDAO等DAO接口和LineOrderDAOlmpl等DAO实现类，在业务逻辑层设计了业务服务接口LyService和接口实现类LyServicelmpl，以及一些工具类，在web层设计了LineOrderBean等BackingBean以及与之协作的ManagedBean、相关工具类;在系统分析设计的基础上，采用Eclipse,Tomcat,SQLServer作为开发工具，利用Spring作为基础架构，使用Hibernate,Spring,JSF分别实现了持久层、业务逻辑层和web层。

实践表明，在web应用开发中，使用整合JSF,Spring,Hibernate的开发平台，可以充分发挥各个框架的优点，降低web应用开发的复杂性，提高开发效率和质量。

关键词:

JSF框架:

Spring框架;Hibernate框架

第一章绪论

1.1研究背景及研究意义

随着计算机网络的迅猛发展，web在各行业中的应用越来越广泛，发挥的作用越来越大。

web已经成为最重要的Internet应用，研究资料显示web通信量占Internet通信量的三分之二以上.作为一种资源的组织和表达形式，web已经成为最重要的信息传输媒介。

越来越多的政府机构、公司、组织创建了基于web的应用系统。

web应用系统己从简单的web站点发展到专业应用程序、电子商务系统和大型的企业级应用系统。

web应用系统的规模不断扩大，复杂程度也呈指数级增长，开发web应用越来越复杂。

web应用系统的体系结构从传统的C/S两层结构，发展到B/S结构，再到现在的多层结构。

通常web应用系统至少可以划分为三个层次:

表示层，对于web应用来说也就是web层，该层向客户提供业务逻辑层的服务，负责处理客户请求，和业务逻辑层交互，并显示结果;业务逻辑层，接收web层的请求，处理业务逻辑;持久层，封装数据库访问逻辑.多层结构相对于两层结构来说，能够降低系统各层之间的耦合，可扩展性好，维护方便。

为了满足企业级应用开发的各种复杂需求，给用户提供可靠、完善的信息服务，微软和sun公司分别推出了.NET和J2EE（现在更名为JavaEE），它们之间的竞争促进了web开发技术的迅速发展.基于JavaEE的web应用以其层次性、可扩展性、安全性、平台无关性得到了大多数公司的认同，已经成为企业级web应用的主要解决方案。

Java平台下传统的JSP/Servlet开发方法优势在于直接简单，对于小型的web应用可以很方便、快速的进行开发，但是这种不加控制的开发方式容易造成以下问题:

整个web应用体系混乱，各种代码混杂，显示、业务和数据的高耦合，难以修改和重用;开发代价太高，不能满足目前大型的web应用开发中普遍要求降低开发团队的技术成本和分工协作难度、缩短开发时间的要求;新的web应用程序开发经常从头开始，难以利用现有成果[I]Et。

基于JavaEE的框架技术是解决上述问题的重要技术[31eEM是Java企业版的一部分，也是一种框架。

传统的EJB是一种复杂的、重量级的web应用解决方案，同时在性能、简单性等方面作出了牺牲[41。

由于EJB的复杂笨重，Spring,Hibernate等开源框架逐渐流行起来，它们为web应用提供了优秀的轻量级的解决方案。

流行的开源框架Spring通常和web框架Struts一起使用，而新兴的web框架JSF比Struts技术更先进;Hibernate是一种成熟的持久层框架，在实际开发中的应用很多.因此本文将Spring.JSF.Hibernate整合起来开发web应用，对于引导项目开发采用先进技术具有指导意义。

并且各个框架的侧重点不同，研究如何把它们整合起来作为一个通用的开发平台，可以充分发挥它们各自的优点，有利于开发高质量的web应用系统。

该web系统开发平台可以满足大多数web应用的需求，可以作为我们日后系统开发的基础开发平台。

这样课题的研究成果具有普遍意义，解决了web应用开发中的常见问题，便于日后进行复用，有利于降低开发成本。

1.2研究现状

在web应用系统的开发中，框架的使用很普遍。

框架使得系统的开发降低了难度，并且复用了良好的设计，使系统的可扩展性、可维护性、灵活性得到了提高。

Java技术的广泛应用，使开源社区推出的框架层出不穷，另一方面，优秀框架的出现既为项目开发提供了方便、可靠的工具，也推动了Java技术的进一步发展。

Java开源社区给我们提供了很多优秀的开源框架，这些框架广泛应用于web应用开发中。

开源框架是建立在Sun公司JavaEE技术基础之上的，它们为开发者提供了更简单的编程模型和其他一些好处。

目前在web应用的各个层次涌现出了很多优秀的开源框架，如web层的Tapestry,WebWork,Struts框架，业务逻辑层的Spring,Hivemind框架，持久层的Hibernate,iBATIS框架。

另外，Sun公司也推出了一种的新的web框架JSF.

web层的Struts框架出现的比较早，应用较广泛，是一种成熟的框架。

JSF是一种新兴的web层框架，也是一种技术标准.JSF采用的是事件驱动型的组件模型，组件模型是一种先进的模型，有利于系统的开发和维护，而Struts只是单纯的MVC框架。

并且JSF是一种彻底的MVC，实现了模型和视图的完全.JSF相对于流行的Struts来说更为先进。

当EJB刚推出的时候，占据了业务逻辑层和持久层框架的主要地位，EJB的功能很强大，主要用于构建大型的、分布式的企业系统，EJB较为复杂，学习、使用起来比较困难，它能够为我们解决构建企业系统所遇到的大部分问题，但是其中的有些特殊问题我们遇到的可能性较小，所提供的功能很多，但我们未必都需要。

EJB相对于现在流行的轻量开源框架来说，属于重量级的框架.EJB专家组也认识到了EJB的缺点，最新的EJB3.0，致力于降低使用EJB的难度和复杂性，EJB3.0借鉴了Spring,Hibernate的成功经验，如O/R映射、IOC,AOPt41，但是和开源框架相比还是不够简单。

持久层框架主要有EJB的实体Bean,Hibernate和iBATIS等等。

良好的持久层框架应当实现对象/关系映射，即ORM。

因为有Hiberante,iBATIS这样的工具帮助我们实现对象和关系数据库表之间的映射，克服了对象和数据库阻抗不匹配问题，所以才使我们能够以面向对象方式来操作关系型数据库系统。

Hiberante是目前很流行的、开放源码的ORM框架。

Hibernate框架在实际开发中使用的很成功，框架本身也很成熟。

其他的持久层框架，如实体Bean,iBATIS都没有Hibernate成功。

目前国内也出现了一些轻量框架，不过没有国外的开源框架应用广泛，影响也不够大。

如国人开发的JDon轻量框架，用于快速开发小型系统，表示层借助Struts实现，提供了用于访问数据库的简单的持久层模板。

1.3研究内容

现在各种框架数目繁多，每一种框架都有其特定的应用范围，没有一种框架能够很好的解决web应用中的所有问题。

因此如何根据所要开发的系统选择合适的框架组合起来，并且使系统中的各个层次以一种松散祸合的方式彼此作用而不用管理底层的技术实现细节，成为我们面临的主要问题.

为了解决以上问题，本课题主要对以下内容展开研究:

研究和分析JavaEE的多层体系结构，了解JavaEE框架国内外发展、应用状况;根据web系统开发平台设计目标，设计平台架构，并对架构各个层次采用的设计模式和持久层的解决方案进行分析，确定持久层的解决方案;通过比较分析各种框架，确定平台架构各个层次的技术方案，搭建web系统开发平台;研究和分析Spring为web应用提供的基础服务以及Spring和JSF,Hibernate框架整合的方法;最后、通过将开发平台应用于一个旅行社电子商务系统的开发中，检验开发平台.

1.4文章结构

第一章:

简单的介绍了课题的研究背景、研究现状、研究内容及研究意义。

第二章:

首先介绍了JavaEE，然后介绍了JavaEE多层体系结构，并分析了多层体系结构的优点。

第三章:

通过各种框架的比较分析，确定平台的架构。

包括平台设计目标、平台架构分层的确定，然后对平台架构各个层次所需注意的问题进行分析，在此基础之上，通过对比分析各种框架选择平台架构各个层次所用的框架，给出了使用所选框架的平台架构，并对Spring和JSF,Hibernate的整合方法进行了分析，对JSF,Spring,Hibernate整合方案和其他整合方案进行了比较分析.后面两章使用前文提出的开发平台实现了一个旅行社电子商务系统。

第四章:

首先介绍了旅行社电子商务系统，其次确定系统的功能需求，进行用例分析和活动流程分析，然后确定系统的功能模块、体系结构、运行环境，最后进行数据库设计、各个层次的类设计以及页面设计.

第五章:

根据前文提出的平台架构以及系统分析设计，实现了旅行社电子商务系统。

以持久层、业务逻辑层、web层的顺序探讨了实现web应用系统各个层次的主要问题。

第六章:

总结了本文的所有工作，并对JavaEE框架的发展做了展望。

第二章JavaEE体系结构

2.1JavaEE简介

JavaEE是Java平台企业版的简称（JavaPlatform,EnterpriseEdition），是一种利用Java平台来简化企业解决方案的开发、部署和管理相关复杂问题的体系结构，用于开发便于组装、健壮、可扩展、安全的服务器端Java应用。

JavaEE是建立在JavaSE基础之上的，并且增加了企业应用所需的类库。

最新推出的JavaEE5是web应用开发平台J2EE诞生六年后的下一代企业级开发规范，JavaEE5着重于简化开发，采用了元数据标注和普通Java对象（POJO）驱动的开发方式，对平台进行了重新定义，增加了基于组件的JSFweb框架、JSTL、新的Java持久化API等，即保持了J2EE的强大功能，又使得开发工作变得简单一些。

2.2JavaEE体系结构

JavaEE的多层体系结构是JavaEE平台提供的基本应用架构，应用逻辑按功能划分为组件分布在不同的层上。

JavaEE多层架构划分为以下几个层次（见图2-1）:

客户层（Client-tier）,web层（Web-tier）、业务层（Business-tier）.EIS层（Enterpriseinformationsystem-tier）.客户层运行在客户机上，用于向客户呈现用户界面，比如动态的html页面;web层和业务层运行在JavaEE服务器上，web层向客户端提供用于交互的JSP页面，接收客户的请求，并调用业务层的，服务组件处理请求，业务层定义业务处理逻辑和数据库访问逻辑，完成业务处理后将结果返回给web层;EIS层运行在数据库服务器上，用于向上层提供数据。

多层结构中，层次的划分不是物理上的划分，而是逻辑上的划分，比如业i务层和EIS层可以在一台计算机上也可以在不同的计算机上。

“逻辑层”是开发人员对各关注点的基础分割，这样我们可以更加容易的划分系统职责，使用逻辑层有助于构筑可以划分为子任务组的应用程序门。

多层结构通过在客户端应用程序和后台数据存储之间增加多线程的应用服务器来扩展常见的B/S（浏览器/服务器）两层结构，解决了两层结构的弊端，在两层结构中，所有的工作都在服务器端完成，服务器端担当了过多的角色而显得臃肿，不利于系统的扩展和维护。

由于多层结构灵活的伸缩性，非常适于网络应用，已经成为web应用系统的主流架构。

23JavaEE多层结构的优点

多层结构的优点是:

1）能有效降低建设和维护成本，简化管理;

多层结构中各层的组件可以单独更新、修改、替换、增加，因此维护更加方便。

由于客户端采用瘦客户机，所以硬件配置要求不高。

当用户需求发生变化时，修改业务逻辑即可，无需改动数目众多的客户机。

2）适应大规模和复杂的应用需求:

组件技术使得大型系统的的设计变得简单可行，并且具有良好的伸缩性。

多层结构使得数据处理从客户端转移到应用程序服务器和数据库服务器。

客户端通过应用程序服务器访问数据库，大大减少了客户端和数据库之间的连接，使得数据库能够保持良好的响应速度。

3）可以适应不断的变化和新的业务需求;

在基于JavaEE的系统开发和维护过程中，技术人员可以根据新的需求，更新组件，调整旧的系统。

4）可以访问异构数据库:

多层结构只要在中间层有相应的驱动就可以访问异构的数据库，无需在客户端安装很多异构数据库的驱动程序，对客户端的要求很低，并且如果数据库发生了变动，只要在中间层修改驱动即可，无需去修改每一个客户端。

5）能有效提供系统并发处理能力;

多层架构将系统划分多个层次分散管理，可以减轻系统压力，提高系统性能。

可以采用多服务器并行处理的方式，保证系统的高可用性。

6）提高系统安全性。

系统在信息访问、传递、存储环节上均有严格的安全措施。

中间层隔离了用户直接对数据库的访问，保证了数据库系统和数据的安全。

第三章JavaEE框架技术及开发平台的搭建

本章首先根据平台设计目标对平台架构各个层次进行分析，然后选择架构各个层次所用的框架，最后对所选框架的整合方法进行了分析，并与其他整合方案进行了比较。

3.1平台设计目标

由于在很多web应用系统开发中遇到的大多数问题具有相似性，因此本文提出的开发平台不应当局限于某一个web系统的开发应用，而应该是一个通用的开发平台，需要解决web应用系统开发中的常见问题，可以应用在常见web系统的开发中。

本平台用于简化JavaEEweb应用开发，为开发可移植、易于扩展、维护简单、重用性好的web应用系统提供高效的、通用的解决方案，能够满足大多数web应用开发的需求。

开发平台应当满足以下要求:

1）架构灵活、可扩展。

这样在需求变化时，可以很方便的添加、修改功能，这对于软件生命周期中持续时间最长代价最大的维护阶段来说，是很重要的。

2）具有分层架构。

通过分层来实现复杂软件的松祸合。

3）可重用.代码和设计能够重用，利于避免重复劳动，降低成本。

4）具有通用性。

能够满足大多数web应用开发的需求。

5）能够缩短web应用系统开发时间，降低开发复杂性。

3.2平台架构分析

3.2.1平台架构分层

架构是构建系统的蓝图，架构本身就是可重用的，架构能够将整个应用的所有设计元素融合在一起[141。

架构是大型软件复用的基础，利于快速开发web应用。

清晰的架构能够保证系统具有扩展性、重用性以及良好的性能。

为了方便应用系统以后的维护和升级，以及使系统具有良好的可移植性，这里使用在B/S结构基础上拓展的多层结构，这样当需求发生变化时，只需修改中间层即可，而客户端在其他层次发生改变时无需进行修改，客户端只用于显示用户界面，保证了客户机的平台无关性。

JavaEE规范中多层架构的业务层所要完成的任务过多，不仅处理业务逻辑，而且还负责对数据库的操作，如果数据库的数据结构发生改变，需要重构整个业务层，对业务层的影响很大，因此将数据访问细节独立出来作为单独的持久层，也就是在业务层和数据库之间增加了一个抽象层，这样底层数据库的变动就不会对持久层以上的层次造成影响，只需要在持久层进行相应的修改.根据前面的分析，平台架构可以化分为以下五个层次:

客户层、web层、业务逻辑层、持久层、数据层.对于web应用来说，客户层通常是浏览器;数据层主要是指数据库等数据源。

下面对平台架构主要的三个层次一web层、业务逻辑层、持久层分别进行分析。

3.2.2web层分析

JavaEE规范使用JSP页面来构建多层架构的web层，通过JSP页面接收客户请求并调用业务层处理请求，如果只是采用JSP页面来构建web层，容易使表示逻辑和请求处理逻辑混杂在一起，造成逻辑的混乱和代码的祸合，影响软件开发质量。

为了避免上述问题，我们在web层采用MVC设计模式来分离表示逻辑和请求处理逻辑，使JSP页面只用于完成显示用户界面的功能，不用将请求处理代码混杂在JSP程序的html代码中，请求的处理由控制器和模型协作完成，处理结果通过JSP页面来显示。

MVC设计模式是随着Smalltalk流行起来的，如今广泛应用于web层的设计中。

MVC模式将应用程序分为相互协调的三部分:

模型（Model）、视图（view）.控制器（Controller）.

模型代表事务数据以及操作数据的规则，模型不知道数据会被如何显示，也不清楚哪个UI组件会被用来修改数据，它如果需要取得视图中的对象或者更户新视图，需要通过控制器来处理，模型的责任是提供一个可供读取数据的公开接口。

一个模型可以被多个视图使用，减少了重复代码，提高了系统的重用性。

视图是模型在屏幕上的表示，模型在操作后，其结果是通过视图显示的;二视图知道关于班的一切细节，视图知道如何通过模型的公开接口读取数据并正确安排数据的显示方式，也知道如何使用控制器的接口以便要求控制器去修改模型里的数据。

视图只是一种数据输出和允许用户操作的方式，在视图中并没有真正的数据处理发生。

控制器定义用户界面输入的相应方式，管理用户与视图的交互，接收来自视图的用户输入，改变模型的状态.控制器在模型和视图之间起到了桥梁的作用，使得模型和视图之间祸合松散，甚至可以彼此不知道对方，由控制器连接两个部分。

MVC模式在处理过程中，首先通过控制器接收用户输入，决定使用哪个模型进行处理，然后模型使用数据操作规则来处理用户输入并返回数据，最后控制器用合适的视图包装模型返回的数据，并通过客户层呈现给用户。

如果不使用MVC，用户界面设计往往将这些对象混在一起，而MVC通过将它们分开来提高灵活性和复用性[15）[161.传统的使用ASP.PHP的web应用开发方式，使得数据处理的代码和表示代码混杂在一起，这种做法虽然在web技术发展的初期受到赞扬，但是随着时间的推移，它的弊端越来越明显.数据处理和表示代码的混杂使得开发出来的应用程序非常复杂、难以阅读、不容易复用，而且不利于以后的维护和扩展。

MVC模式从设计上将数据从表示层分离开，尽管开发MVC应用程序需要增加一些工作量，但是它能够带来很多好处。

使用MVC模式的web应用系统有以下优点:

a.通过分离数据和其表现，使得添加或删除一个用户视图变得很容易，甚至可以在程序执行时动态的进行，并且模型和视图可以各自单独开发，增加了程序的可维护性、可扩展性，使测试更加容易:

b.控制逻辑和用户界面分离，使程序能够在运行时根据工作流、用户习惯或者模型状态来动态选择不同的界面，满足了用户对数据操作的多样性和复杂性的要求;c.对于开发人员来说，由于MVC分离了数据控制和数据表现，有助于分清开发者的职责，后台的开发人员可以专注于数据的处理，前台开发人员专注于用户界面的设计，从而可以提高开发效率和开发质量。

3.2.3业务逻辑层分析

业务逻辑层是系统架构中体现核心价值的部分，它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计。

业务逻辑层在体系架构中的位置很关键，处于web层和持久层之间，在数据交互中处于承上启下的作用。

修改业务逻辑只需在中间层进行，客户端仍然可以使用原来的程序，给维护工作带来了极大的便利，并且提高了执行效率。

业务逻辑层可以采用外观模式来减少子系统之间的通信和依赖关系。

外观模式（Facade）为子系统中的一组接口提供了一个一致的界面，Facade定义了一个高层接口，这个接口使得这一子系统更加容易使用p5。

使用Facade模式可以带来以下好处:

隐藏子系统组件，减少了客户处理的对象的数目使得子系统使用起来更加方便:

实现了客户和子系统之间的松祸合、子系统内部组件之间的紧祸合，使得子系统内部组件的变化不会对客户造成影响;有助于建立层次结构系统，并且有助于将对象之间的依赖关系分层。

3.2.4持久层分析

持久层是负责从一个或多个数据库中存入和取出数据的一组类和组件，用于定义、维护、访问、更新数据并管理和满足应用服务对数据的请求.在JavaEE多层应用程序的开发中，持久层设计对整个系统的开发进度、可移植性、性能起着至关重要的作用。

持久层通常也是系统最容易失控的地方，开发者往往低估构建他们自己的持久层框架的挑战性。

3.2.4.1持久层解决方案

持久层解决方案主要有以下几种:

基于JDBC的解决方案;基于持久层框架的解决方案:

基于EJB的解决方案。

第一种方案简单直接，适用于开发小型的应用，然而由于JDBCAPI是底层API而且容易出错、不易修改、重复代码过多，因此直接使用JDBC开发的系统，重用性、可扩展性、维护性较差，数据库或对象属性的变动都将影响业务逻辑代码。

第二种方案对JDBC进行了封装，将工作量最大的工作，也就是对象关系映射，交给第三方的持久层框架进行处理，大大减少了编码量。

面向对象是目前流行的编程思想，而关系型数据库系统仍然是主流的数据库技术，因此二者之间的矛盾是必然的[211。

解决对象和关系之间的阻抗不匹配问题，实现O瓜映射是持久层设计的核心问题[221。

优秀的持久层框架可以实现对象关系映射，实现了面向对象应用程序与关系数据库系统之间的松散藕合，提高了持久层的开发效率和系统的可移植性、维护性[231，并且通过对数据访问中各种资源和数据的缓存调度，实现了更好的性能。

第三种方案使用EJB的持久化方案。

EJB2.1持久化模型过于复杂而且存在基础性的缺陷。

传统的EJB实体Bean是一个实现活动记录模式的组件框架，每个实体Bean被映射到数据库表中的一行。

活动记录模式将业务逻辑和持久化逻辑分离到不同的类中.最新的EJB3.0吸收了开源ORM框架的优点，采用了渐的持久化方式。

使用EJB的持久层依赖于EJB容器，并且与重量级的EJB编程模型紧密祸合，对于常见的没有分布式要求的需